e2e200 en 40 change control management 2007

© SAP AG 2006

E2E200 Change Control Management

THE BEST-RUN BUSINESSES RUN SAP

© SAP AG 2007

E2E200Change Control Management

SAP Solution Manager 4.0 2007/Q2 Materialnummer: 50084558

© SAP AG 2006

Copyright

Copyright 2007 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, System i, System i5, System p, System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the express prior written permission of SAP AG.

This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may be changed by SAP at any time without notice.

SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.

SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence.

The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.

© SAP AG 2006, Title of Presentation / Speaker Name / 1

Required Knowledge:

Fundamentals of SAP Software Change Management

Basics of SAP Solution Manager

Recommended Knowledge:

End to End Solution Support (E2E050)

Course Prerequisites


This course will enable you to:

Course Goals

Understand the value of E2E Change Control Management.

Describe the concept and methods of E2E Change Control Management.

Leverage the SAP Solution Manager as an application platform for E2E Change Control Management.


This course is intended for the following audiences:

Application Management Experts

Change Control Engineers

Test Managers

Support Managers and members of the Customer’s SAP Competence Center (CCC)

Partners and System Integrators for the Run phase

Technical Quality Managers

SAP Service and Support Engineers

Duration: 5 days

Target Audience

Notes to the user: The training materials are not teach-yourself programs. They complement the course

instructor's explanations. On each page, there is space for you to write down additional information.


Unit 6 Transport Strategies

Unit 7 Change Request Management

Unit 8 Maintenance Management

Unit 9 Test Management

Unit 10 IT Reporting for Change Control

Unit 1 Introduction to E2E Change Control

Unit 2 Solution Landscape Documentation

Unit 3 E2E Change Diagnostics

Unit 4 NetWeaver Development Environments

Unit 5 Enhanced Change and Transport System

Preface

Appendixes

Course Content


End-to-End Curriculum

E2E050E2E Solution Support

E2E100E2E Root Cause Analysis

5 days

E2E200E2E Change Control Management

5 days

E2E300E2E Integration & Automation

5 days

E2E400Technical Upgrade Management

2 days

C_E2E100Application Management Expert – Root Cause Analysis

C_E2E200Application Management Expert – Change Control Management

C_E2E300Business Process Expert

C_E2E400Technical Quality Manager for Upgrade Projects

© SAP AG E2E200 1-9

© SAP AG 2007

E2E Change DiagnosticsSolution Landscape Documentation

Netweaver Development EnvironmentsEnhanced Change and Transport SystemTransport StrategiesChange Request Management

Introduction to E2E Change Control Management

Test ManagementMaintenance Management

IT Reporting for Change Control


© SAP AG E2E200 1-10

© SAP AG 2007


ContentObjectives of SAP E2E Change Control Management

Standards for SAP E2E Solution Operations

Standards for SAP E2E Change Control Management

Change Diagnostics

Change Deployment

Change Request Management

Maintenance Management

Test Management

© SAP AG E2E200 1-11

© SAP AG 2007

Introduction to E2E Change Control Management: Unit Objectives

At the end of this unit, you will be able to explain:Objectives of SAP E2E Change Control Management



Change Diagnostics

Change Deployment



Test Management

© SAP AG E2E200 1-12

© SAP AG 2007

Introduction to E2E Change Control Management: Unit Overview Diagram


Lesson 2: Standards for SAP E2E Solution Operations

Lesson 3: Standards for SAP E2E Change Control Management

Lesson 1: Objectives of E2E Change Control Management

© SAP AG E2E200 1-13

© SAP AG 2007

Objectives of E2E Change Control Management

ObjectivesTransparency of current software configuration and recent changesFast realization of business demandsDefined approval procedure for change requestsHigh quality and stability of the production environment

© SAP AG E2E200 1-14

© SAP AG 2007

Defined Approval Procedures


Transparency of current software configuration and recent changes

Change Diagnostics


SAP Standards for E2E Change Control Management

Fast realization of business demands

Change Deployment

High quality and stability of the productive environment


Test Management


© SAP AG E2E200 1-15

© SAP AG 2007

Different Focus of Business Unit and IT

Fast reaction on business demands

Less formalism and bureaucracy

Less time to test

Focus on own business

Solid operation

Solid change management

Only planned transports

Only tested and approved changes into production

Business Unit IT

Often there is a conflict between business requirements for fast changes and operation requirements for stable environments.

© SAP AG E2E200 1-17

© SAP AG 2007

System diagnostics/administration

SAP NetWeaver Team

Application ManagementUpgrade & life cycle management, application diagnostics

Business Process OperationsIntegration & automation

Standardized E2E Solution Operations

Customer’s Business Unit

Global Business ProcessChampion

Regional Business Process Champion

End UserIncident and

problem management

PMO(Program Office)

Requestsfor change

Custom Development

IT Infrastructure

SAP Standards in Operations reduce Total Cost of Operations and enable Mission Critical Support

Customer’s IT

The first step for the efficient operation of E2E solutions is the specialization of organizations. Dedicated stakeholders are responsible for different objectives. The stakeholders can be arranged into different organizations that can be grouped largely into the two key organizational areas: Business Unit and IT.

On the business side, most stakeholders are end users. They use the implemented functionality to run their daily business. Some end users have specialized knowledge about the business applications. These key users provide first-level support for their colleagues. Business process champions have the lead role within the business units. They define how business processes are to be executed. A program management office communicates these requirements to the IT organization, decides on the financing of development and operations, and ensures that the requirements are implemented.

On the technical side, the customer IT organization has to ensure that the services provided by the SAP solution are available for the business units. The application management team is in direct contact with the business units. It is responsible for implementing the business requirements and providing support for end users. To do so, the application management team is supported by other organizations within IT. Business process operations cover the monitoring and support of the business applications, their integration, and the automation of jobs. Custom development takes care of adjusting the solution to customer-specific requirements and developments. SAP technical operations are responsible for the general administration of systems and detailed system diagnostics. The IT infrastructure

© SAP AG E2E200 1-18

organization provides the underlying IT infrastructure (network, databases, …). Further specialization is also possible within these organizations. For example, there may be individual experts in different applications within SAP technical operations.

© SAP AG E2E200 1-19

© SAP AG 2007

SAP Standards for E2E Solution Operations

Incident Management

Business Process ChampionException HandlingData Inconsistencies

Program Management OfficeChange Request ManagementUpgradeEnterprise Service-Oriented Architectures

Application ManagementRoot Cause AnalysisChange Control ManagementMinimum DocumentationRemote Supportability

© SAP AG E2E200 1-20

© SAP AG 2007

SAP Standards for E2E Solution Operations

Business Process OperationsBusiness Process and Interface MonitoringData Volume ManagementJob Scheduling ManagementTransactional Consistency

Custom Development

SAP Technical OperationsSystem AdministrationSystem Monitoring

© SAP AG E2E200 1-21

© SAP AG 2007

Technical Core Competence (Associate)

Customer’s Business Unit

Curriculum for SAP Solution Operations

PMO(Program Office) Application Management

Business Process

OperationsSAP NetWeaver Team

Customer’s IT

SAP System Administration

E2EBusiness Process

Integration & Automation

E2EChange Control

Management

E2ERoot

Cause Analysis

SAP Technology & E2E Solution Support SAP Technology

Technical Expert Competence (Professional)

EP Admin

XI Admin

BI Admin

Core WebAS(DBs)

Security

Management Competence(Master)

TechnicalQuality

Management

TechnicalUpgrade

Management

EP Diag

XI Diag

BI Diag

WebAs (DBs)Diag

Change Request

Software Log.

Test Mgmt

BusinessProcess

PerformanceJob

Scheduling

DataVolume Mgmt

Integration Mgmt

SolMan Impl.

© SAP AG E2E200 1-23

© SAP AG 2007

Control the Changes during the whole Application Livecycle

Global / RegionalBusiness Process Champion

Solution Architecture

Solution Design

Program Management OfficeChange Request Management

DB / OS / HW Changes & MaintenanceIT Infrastructure

Solution Maintenance

SAPMaintenance Management

Solution Correction

End User / Key UserIncident Management

Application ManagementApplication Change

Test Management Change Deployment Diagnostic

Workbench / Customizing Changes

Custom Development

Correction & Transport System Change System Diagnostic

SAP NetWeaver Team

The program management office is the central group in the customer business unit that is responsible for the overall planning, implementation and continuous improvement of the business processes in the solution landscape. All requests for changes, including Solution Design, Solution Maintenance, Solution Correction flow through this office and need to be integrated into a schedule of landscape changes. As such, change request management takes is a large part of the program management office’s activities. This office is responsible for managing everything from day-to-day changes and adaptations to all release planning and major infrastructure technology shifts. In addition, these activities must be aligned with all stakeholders.

The key interface between business and IT is the application management organization. End-users, key-users and the program management office use the services of IT for a wide variety of task; from solution landscape planning to implementation, from business unit re-quest handling to execution, from documentation standards, training and certification to management level reporting. Being such a central component, several of the introduced roles use the application management platform as their central working application.

It is essential that changes to the solution landscape are managed carefully to ensure transparency. The Change Request Management standard ensures that standardized methods and procedures are used for the efficient and prompt handling of all changes. In addition to change request management, the deployment and the analysis of changes need to be addressed, to ensure that changes are executed without disrupting ongoing business. This is

© SAP AG E2E200 1-24

the focus of the Change Control Management standard. The standard covers two major areas of change control: Change Deployment and Change Diagnostics for Application and System Changes.

© SAP AG E2E200 1-25

© SAP AG 2007






Change Deployment


Change Diagnostics


Test Management

© SAP AG E2E200 1-26

© SAP AG 2007

Change Diagnostics – Typical Questions

Is there ONE place where all changes in the

solution are listed

Did we changeany technicalconfigurationparameters?

How manytransports were

imported last week?

When did weimport support

packages?

Did we changeanything last

Tuesday?

Change Diagnostics supports customers in identifying, controlling, maintaining and verifying the versions of configurations and the values of parameters of the solution landscape components. Accurate information about configurations and their documentation is necessary to support auditing requirements and other solution operations processes. To track changes, the configuration information is recorded regularly inside the components and collected centrally in the SAP Solution Manger database. The configuration can be compared to a template or master configuration to analyze changes. The reporting includes all current and historical configuration data throughout the application life cycle. Together with Change Request Management and Change Deployment, Change Diagnostics supports the transition from project to operations and the management of code and configuration freeze phases.

© SAP AG E2E200 1-27

© SAP AG 2007

Change Diagnostics: Overview

Technical Configuration

Business Configuration

“Content”EP, XI, BI, SLD

CodingPatches, SP,Release

Productive Environment

Documented in SAP Solution Manager (SMSY)

Type of changes

Changes toProduction

Enhanced Change and Transport SystemConfigurationand File

Reporting

Tools

E2E Change Analysis

This figure shows the different tools in E2E Change Diagnostics Configuration and File Reporting extract configuration parameters from Java or ABAP based

systems and display the parameters and their history in Solution Manager Diagnostics. The Change and Transport System records change to Business Configuration (Customizing

Requests) and Coding (Workbench Requests). The new Enhanced Change and Transport System is also able to transport Non-ABAP objects, such as Java archives.

Releases, Support Packages and Patches are documented in SAP Solution Manager (SMSY). E2E Change Analysis provides BI based reporting on all of the changes in a solution.

© SAP AG E2E200 1-28

© SAP AG 2007

Capture and Manage the system landscape centrally in SAP Solution Manager

CUS

SCM

CUS

FVS

4.6C

PLM Solution Landscape

Solution Manager System Landscape

(SMSY)

server, databases, systems, system components

System Landscape Directory

Functions of Solution Manager System Landscape (Transaction SMSY) include: Creating landscape components: server, databases, systems, system components Defining non-SAP products for use in the system landscape maintenance Automatic data read and save via ABAP main instances Overview of system groups Generating RFC destinations to component systems; RFC connection errors are logged Manual data capture, for example, servers, non-ABAP and planned systems Graphic display • Landscape components (servers, databases, systems) • Assign attributes to landscape components

Analysis of system landscape by components

© SAP AG E2E200 1-29

© SAP AG 2007

Change Analysis, Configuration & File Reporting -Architecture Overview

InfoCube

E2E Change Analysis

ABAP based installations

Solution Tool Plugins

JAVA based installations

SMD AgentsSolution Manager Solution Manager DiagnosticsDiagnostics

ConfigConfig StoreStore

Configuration and File Reporting

Data Collectiononce a day

Data Collectiononce a day

Number of Changes

Parameter Values

The data is collected in Java based systems via SMD Agents and in ABAP based systems via Solution Tool Plugin Extractors.

E2E Change Analysis uses the same tables as Configuration and File Reporting. It enhances the functionality of the previous Configuration and File Reporting by adding data

from ABAP based systems and by providing BI based reporting capabilities.

© SAP AG E2E200 1-30

© SAP AG 2007

Change Diagnostics: Characteristics

Change Diagnostics provides transparency on the current softwareconfiguration and recent changes in the solution landscape.

Change Diagnostics:Efficient Root Cause Analysis: Provides a central entry point for analyzing changes in a solutionProvides accurate information on configuration parameters and their history. For example, database parameters, ABAP parameters and JAVA parameters.Enables the organization to standardize the solution configurationDocumentation of the solution landscape in the SAP Solution ManagerTransport statistics and KPI’s on the quality of the solution

© SAP AG E2E200 1-31

© SAP AG 2007

Introduction to Change Control Management: Unit Overview Diagram





Change Deployment


Change Diagnostics


Test Management

© SAP AG E2E200 1-32

© SAP AG 2007

Change Deployment – Typical Questions

Is our development system up to

date ?

Did we record application

changes automatically ?

How can we change ABAP &

Java components

synchronously ?How can we

avoid transport sequence

errors?

How to manage heterogeneous development

environments?

© SAP AG E2E200 1-33

© SAP AG 2007

Enhanced Change and Transport System (CTS+)

ABAP change

Java change

…

ABAP change

Java change

…

ABAP CTS

Legend

logical transport route of non-ABAP objects

physical transport route of non-ABAP objects

check-in/check-out of non-ABAP objects

transport route of ABAP objects

ABAP Transport Controller

Non-ABAP

Virtual QAS Virtual PRD

Java DEV Java PRDJava QAS

SAP NetWeaver Application Server CTS+

Non-ABAPNon-ABAP

Transport of ABAP transport objectsEnterprise Portal objects (EPA, PAR)Objects of NWDI (SCAs,…)Objects from XIInterface for Non-SAP applications

The Enhanced Change and Transport System (CTS+) improves the established ABAP Change and Transport System, to manage transport of ABAP and non-ABAP-objects centrally.

Changes from heterogeneous development environments can be transported with the ABAP Change and Transport System and mixed objects (ABAP, JAVA, …).

It allows synchronized changes to business processes which run in ABAP and JAVA A Java transport landscape is represented by an ABAP transport landscape. The transport controller must be a physical ABAP system (at least NW04s, SPS12) in which

the transport routes are configured. Transport Requests are created on the transport controller. The Java Development Environment checks in Java Archives into the transport request. Then the transport request is imported into the virtual non-ABAP systems. In the After-Import

Method the Java Archives are deployed e.g. via Software Deployment Manager Non-ABAP applications inherit all properties of the ABAP Change and Transport System in

terms of documentation, tracking and troubleshooting features

© SAP AG E2E200 1-34

© SAP AG 2007

Change Deployment: Characteristics

Change Deployment provides tools and best practises on how to develop and distribute changes within a system landscape on a technical level.

Change DeploymentManagement of heterogeneous development environmentsOne common tool for software logistics of ABAP and non-ABAP systemsNon-ABAP applications inherit all properties of the ABAP Change and Transport System in terms of documentation, tracking and troubleshooting featuresConsistent distribution of changes within a solutionSAP‘s best practises in transport management

© SAP AG E2E200 1-35

© SAP AG 2007






Change Deployment


Change Diagnostics


Test Management

© SAP AG E2E200 1-36

© SAP AG 2007

Different Levels of Control


SAP Solution Manager

Enhanced Change and Transport System (CTS+)SAP System ABAP Stack

ABAP

BetterControl

BetterControl

ImprovedDocumentation


Java .net …..

Change Request Management in SAP Solution Manager is 100% compliant with the Enhanced Change and Transport System.

On the lowest level, transports are executed with proprietary Java tools. These Java tools can be controlled by the Enhanced ABAP Change and Transport

System (CTS+). This allows a better control of transports. Furthermore, the documentation, tracking and troubleshooting possibilities are improved.

On the next level of control, transports in the ABAP Stack can be managed by Change Request Management in SAP Solution Manager. This increases the control of the full change process, including the incident, approval process and change realization process.

© SAP AG E2E200 1-37

© SAP AG 2007


Change Request Management – Sample Process

Change Request

Service Message

Developer

Requester

Tester

DEV

IT Operator

QAS

PRD

Service Desk Employee

Serv

ice

Des

kC

hang

e R

eque

stM

anag

emen

t

ChangeDocument

Maintenance Cycle

TaskList

Feedback

Controlled transports


ChangeManager

An end user or key user uses the service desk to create a service message. This service message triggers a corresponding change request. The change request may affect various cross-components. After the program management office approves the change request, the application management organization performs related activities to realize the change request, for example, developing, testing and roll out.

© SAP AG E2E200 1-38

© SAP AG 2007


Three Tiers of Change Request Management

Management of all change requests

Change request categorization

Change documentation

Approval workflow

Status reporting

Complete change history

Change Admin

Customizing & Development (Realization)

Test execution

Seamless integration into TMS

Transport scheduling

Transport tracking

Change LogisticsProject Management

Project planning & budgeting

Project documentation

Customizing & Development (Specifications)

Test management

© SAP AG E2E200 1-39

© SAP AG 2007

Change Request Management: Characteristics

The goal of Change Request Management is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, therefore improving day-to-day operations.

Characteristics of Change Request Management:Transparency of all software changesFull documentation of each change: Each change in the system has a link to a Change Request and a Service DeskChanges can be scheduled according to priority, category and possible impactAll changes have to follow an established workflow. Only changes which are approved and tested come into productionChange Request Management incorporates SAP’s best practises in transport managementManagement of Non-ABAP systems is possible

© SAP AG E2E200 1-40

© SAP AG 2007






Change Deployment


Change Diagnostics


Test Management

© SAP AG E2E200 1-41

© SAP AG 2007

Enhancement and Maintenance to adopt Innovation

New Enterprise Services

Industry-Specific Enhancements

Process and User Interface Simplification

Cross-Industry Functional Enhancements

Customers Adopt Innovation at their Pace

mySAP ERP 2005

SAP NetWeaver

2006 2007 2008 2009 20102005

NextRelease

Enhancement Packages

The maintenance strategy for SAP applications is based on the following principles: SAP offers three successive maintenance phases: mainstream maintenance, extended

maintenance, and customer-specific maintenance. SAP provides support packages during mainstream maintenance and extended maintenance.

The delivery frequency of support packages is dependent on the maintenance phase. As part of its release strategy, SAP announces the planned duration of the mainstream

maintenance period for a release as soon as the release is announced. For SAP applications based on SAP NetWeaver 2004 and higher, SAP usually applies the 5-1-

2 maintenance strategy: Five (5) years of mainstream maintenance One (1) year of extended maintenance (currently at an additional 2% fee) Two (2) years of extended maintenance (currently at an additional 4% fee) SAP is changing the SAP ERP major release schedule to a five-year rhythm, to align it better

with the customer adoption cycle. To ensure that customers take advantage of innovations while minimizing the impact to core operational systems, SAP plans to accelerate delivery of new functionality through enhancement packages that customers can opt to implement on top of SAP ERP 2005. Enhancement packages are intended to contain functional enhancements and enterprise services in areas such as shared services, end-to-end business processes such as order to cash or hire to retire, supplier collaboration, and industry-specific functionality. We

© SAP AG E2E200 1-42

intend to deliver more innovation, quicker and in a more accessible way. SAP is thus ensuring the greatest possible protection of your investments by continuing to deliver high-quality ERP functions. We plan to deliver the next ERP release in 2010.

To find further information, please visit SAP Service Marketplace at service.sap.com/erp and service.sap.com/maintenance.

© SAP AG E2E200 1-43

© SAP AG 2007

R/3

Support Package Stacks (SP Stacks)

Appl.ABABasisKernel

Appl.ABABasisKernel

Appl.ABABasisKernel

SAP releases sets of Support Packages per product and per quarter –the SAP Support Package Stacks (SP Stacks)Support Packages & patches of SP Stacks must be used in the given combination.Other combinations only apply in exceptional casesHigher quality and ensured compatibility of included Support PackagesSimplified download of included Support Packages from a one page summaryAccelerated application, lower cost of operations and system maintenance

APO

BW

tQ1 Q2 Q3 Q4

Patch: Correction of single errors Published on demand Support Package: Collection of program corrections and updates to a particular software

component Includes all corrections and updates since the last Support Package Published regularly according to schedule Support Package Stack: Set of Support Packages for a particular product version that must be

used in combination Reduction of complexity and dependency of Support Packages Same tools and technologies for importing Support Package types

SAP recommendation: Apply a Support Package Stack as a whole to update an SAP system

© SAP AG E2E200 1-44

© SAP AG 2007

Maintenance Schedule

Market CampaignComplaint Management

SAP Maintenance

Rollout Brazil

Implementation Projects

2007 2008 2009

One or twotimes per year

SP Stack

Hot News Top Notes

Periodic review and corrections….….

Urgent Corrections Notes/PatchesIncident ….

SAP HotNews Contains solutions for customer problems with very high priority, such as systems standstills

or data loss Allows customers to filter and display SAP HotNews for their chosen components

SAP TopNotes

Inform you about on potential hot spots in your projects Published on a monthly basis Represent the ten most important SAP Notes for each component Reviewed monthly by experts in the relevant departments and updated based on the current

SAP Note customer usage rate

© SAP AG E2E200 1-45

© SAP AG 2007

Optimized Process for support package stacks


Maintenance Optimizer

Approve Import

Test

Release to production

Download

Approve download

Display relevant corrective SAP software packages


SAP HotNewsInbox

Approve Import

Test


Download

Decide on relevance

Retrieve relevantHotNews from SMP

The Maintenance Optimizer controls the download of software patches and updates for all software components from SAP and from partners.

SAP HotNews Inbox controls the process from retrieving, deciding on relevance and implementing Hot News

© SAP AG E2E200 1-46

© SAP AG 2007

Maintenance Management: Characteristics

The goal of Maintenance Management is to keep applications up todate and to proactively eliminate known software errors. This improves the quality and stability of the solution.

Characteristics of Maintenance Management:Support Packages eliminate already known software errors and improve the quality and stability of the solutionSupport Packages include the most recent legal changesTroubleshooting is faster on a current support package levelas many possible root causes are already eliminatedImplementing a SAP note often requires the implementation of many dependent notes if the support package level is oldImplementation projects or connected systems often require a current support package level

© SAP AG E2E200 1-47

© SAP AG 2007






Change Deployment


Change Diagnostics


Test Management

© SAP AG E2E200 1-48

© SAP AG 2007

Testing along the Software Lifecycle

Implementation ProjectProject

PreparationRealization

Development, TestBusinessBlueprint

Final Preparation and Go Live

Test Concept

Unit Test (Debugging)

ReviewReview

Regression Test / Volume Test

Use

r Acc

epta

nce

Test

OK

Functionalsign off

Systemsign off

Test planning

Inte

grat

ion

Test

BusinessBlueprint Doc

Test Case Development

Bug

Fix

ing

Bug

Fix

ing

Testing & Bug Fixing is ~30% of total project effort

OK

On average, testing and bug fixing consumes 30% of the project resources and duration. Testing will be planned accordingly.

The coarse testing phases are scheduled during the project planning and preparation. The test coordinator plans the test phases in detail and supports the project manager in coarse planning.

During the business blueprint phase, the test coordinator develops the test concept with support from the technical implementation team and the business analyst. The test coordinator ensures that while the business blueprint structure is built, test cases are described and developed according to the business processes. Testers for the first test phase are nominated and invited.

An update of the test concept is required before each test phase. The test coordinator verifies the test cases and ensures the creation and update. The test coordinator creates a test plan and tester assignment for each test phase.

© SAP AG E2E200 1-49

© SAP AG 2007

Test Management: Characteristics

The goal of Test Management is to provide efficient and smooth procedures for manual and script-based testing.

Test Management Benefits: Reduces project costs and effort significantlyContinuous tracking and status analysis of the test progressClear and detailed test descriptionsReproducible test resultsIdentification of the most important test cases

The testing effort is between 20 and 30 percent of the total project effort. For maintenance projects, like support package implementation and upgrades, it can be as much as 70 percent

© SAP AG E2E200 1-50

© SAP AG 2007


Unit 7 Change Request Management

Change Diagnostics

Unit 2 Solution Landscape Documentation

Unit 3 E2E Change Diagnostics

Unit 10 IT Reporting for Change Control

Course Content

Change Deployment

Unit 4 NetWeaver Development Environments

Unit 5 Enhanced Change and Transport System

Unit 6 Transport Strategies


Unit 8 Maintenance Management

Test Management

Unit 9 Test Management

© SAP AG E2E200 1-51

© SAP AG 2007

End to End Diagnostics: Unit Summary

You should be able to explain:Objectives of SAP E2E Change Control Management



Change Diagnostics

Change Deployment



Test Management

© SAP AG E2E200 2-52

© SAP AG 2007






Solution Landscape Documentation

© SAP AG E2E200 2-53

© SAP AG 2007

Contents:

SAP Solution Manager System Landscape


Solutions

Projects

Business Processes


© SAP AG E2E200 2-54

© SAP AG 2007

Solution Landscape Documentation: Unit Objectives

At the end of this unit, you will be able to:Explain the Architecture and Use Cases of the Solution Manager System Landscape

Keep the Solution Landscape Documentation up to date, by using automatic data collection procedures within SAP Solution Manager and System Landscape Directory

Define and tailor Solutions to manage productive systems

Use Solution Manager Projects to manage complex implementation projects

Document business processes in the SAP Solution Manager

© SAP AG E2E200 2-55

© SAP AG 2007

End-to-End Business Processes are a Challenge for Solution Operation

CRM

R/3

BW

EP 7.0

LegacySystem

Spread Sheet

Outlook

Siebel

PeoplesoftHR

XI

Manugistics

EP 6.0

External Web

Documentum

In the last few years, the IT world of SAP customers has become much more complex. Instead of one single R/3 system there are now extensive system landscapes distributed over the entire globe and involving different SAP.com-solutions. Therefore, it has become much more complicated to keep track of the whole system landscape. If something goes wrong within the solution landscape, it is much more difficult to judge the relevance for other activities. It is, therefore, much more important to have an operational concept for the customers solution landscape.

© SAP AG E2E200 2-56

© SAP AG 2007

SAP Solution Manager Architecture

Projects

Solution

Roadmap, Blueprint and ImplementationMaintenance OptimizerChange Diagnostics

Service Desk


Testing


Application Manage-

ment

Systems

NWBI

Other

BusinessProcesses

Documentation

SAPERP

NWXI

Implementation Content

BPR

As the central instance, SAP Solution Manager provides a variety of centralized services for implementing and operating your SAP solutions.

The advantages are: • One central point of access • End-to-end process control • Guaranteed consistency within your system landscape • Dependencies between different components are taken into account

© SAP AG E2E200 2-57

© SAP AG 2007

Solution Landscape Documentation Unit Overview Diagram


Lesson 1: Solution Manager System Landscape (SMSY)

Lesson 2: System Landscape Directory

Lesson 3: Solutions

Lesson 4: Projects

Lesson 5: Business Processes

© SAP AG E2E200 2-58

© SAP AG 2007

Solution Manager Data Model (Transaction SMSY)

ABAPClient 002

Solution 2

Customer system landscapes

Solution 1

Main Instance

Client 200

Client …

J2EE

TREX

PRDsystem

DEV system

QAsystem

…system

PRDsystem

DEV system

QAsystem

…system

Logical component A

Logical component B

Project 2Project 1

Logical component A

Logical component B

DEV QA

Product

System

Product System / Product Version

PRD

DEV QA PRD

Logical component A

Logical component BDEV QA PRD

DEV QA PRD

LogicalSystem

A logical component is an administration unit, which uniquely assigns logical systems to system roles for a product throughout the system landscape and across projects.

For example, we can have the Logical Component Z_ERP, defined for Product SAP R/3, with Product Version 4.6C and Main Instance ‘R/3 Server’ containing the three systems R3D, R3Q and R3P with the roles of Development, Quality and Productive respectively.

A product can have several Main-Instances. For example, SAP CRM consists of CRM Server, TREX, CRM IPC, CRM Mobile Client. It is defined that process steps can only run on ‘Logical Components’. On the other hand, a business process step can be executed on ‘implementation relevant’ Main-Instances. Therefore, you can have one Logical Component for every implementation relevant Main Instance of a product.

© SAP AG E2E200 2-59

© SAP AG 2007

How to Create Systems in SMSY

Pull via RFC

SAP Solution Manager SAP ABAP System

SMSY

1. Choose Product

2. Create New System

3. Setup RFC Destinations

4. Read System DataSAP Java System

No automatic data transfer

Start TX SMSY and open the Landscape Components view. Right click on right product category and choose “Create New System”

Enter a system ID Accept the automatically proposed product and product version Select your main instance and save the entries Establish the RFC connection to SAP Solution Manager to communicate with the satellite

system (ABAP) in order to import its data. This is not possible for Java; you have to do it manually

For automatic data capturing, start the TX SMSY_SETUP and configure the sources with the time interval

© SAP AG E2E200 2-60

© SAP AG 2007

System-Demo SMSY

System-Demo

© SAP AG E2E200 2-61

© SAP AG 2007

Create New System

To create a new system, select the product and right click on it. You can then create a new system either manually or using a wizard

© SAP AG E2E200 2-62

© SAP AG 2007

Setup RFC Destinations

RFC Read Access: RFC to read data from satellite systemsRFC for Change Manager: RFC for Change Request ManagementTrusted System RFC: Log on to managed system as trusted user RFC for Solution Manager: Log on to managed system

RFC destinations can be set up using an RFC wizard. During the process of setting up the RFC destinations, you need to log on to the managed system as a user who is allowed to create RFC destinations in the managed system and to create users for RFC logon.

For detailed information on creating RFCs with the Solution Manager System Landscape, see the online documentation of the Solution Manager System Landscape (Transaction SMSY -> Help -> Application Help -> System Landscape Management -> Create Systems -> Generate RFC Connections).

© SAP AG E2E200 2-63

© SAP AG 2007

Read System Data

Automatically collect data on Clients and Support Package Levels

When the RFC connections are available, you can read system data from the managed systems.

You can access information about clients, software components and support package levels

© SAP AG E2E200 2-64

© SAP AG 2007

Schedule Periodic Data Transfer

Schedule an automatic data transfer once per dayAll systems in SMSY are updated.New systems can be added from TMS or SLD

Transaction: SMSY_SETUP The automatic data transfer refreshes data for all systems which are known in the SMSY and

for which RFC-data is available. In addition data on new systems can be collected if these systems are known in the TMS or in

a connected SLD

© SAP AG E2E200 2-65

© SAP AG 2007

Use Cases of Transaction SMSY

Automatic reporting on Version Information of installed software components. You no longer have to gather this information manually, for example, in Excel sheetsImpact Analysis in the case of hardware and software changes or in case of unplanned downtimesCheck system inventory in case of as-is analysis in projects, system landscape planning or in order to guarantee a homogeneous system landscapeSolution Manager Key Generation in case of installation or upgrade to SAP NetWeaver04s based solutions and higher

Impact Analysis with the function where used list. System inventory with TX SMSY -> Utilities -> Analyses Generate License Key TX SMSY -> Other Object -> enter system on which you want to

install/upgrade SAP ECC -> Generate Installation/Upgrade Key

© SAP AG E2E200 2-66

© SAP AG 2007

Data Source

SID, Product, Main Instance

Installation Number

Message Server, System Nr., DB

Software Components and version information

Transaction SMSY: Software and Hardware Inventory

Central maintenance of the whole system landscape Overview of all component systems in a complex system landscape Administrative basis for work in projects and monitoring One central maintenance environment for all parts of the system landscape

© SAP AG E2E200 2-67

© SAP AG 2007

Where Used List of Systems

© SAP AG E2E200 2-68

© SAP AG 2007

System Landscape Analysis

System landscape analysis by landscape components(Transaction: SMSY Utilities Analyses)

Reporting for servers, databases and systems Tabular overview of, for example, support package levels, software components Standard list functions, for example, filters, download

© SAP AG E2E200 2-69

© SAP AG 2007

Generate Installation Key

1.2.

Details in Note 811923

Goto Transaction SMSY. In order Choose from the Menu: Main Instance | Other Object … Insert SID, Push “Generate Installation/Upgrade Key” Button In the next Pop-up insert “system number” and “message server” Push “Generate Key” Button

Details about the prerequisites can be found in note 811923.

© SAP AG E2E200 2-70

© SAP AG 2007

Solution Manager Unit Overview

SAP Solution Manager Introduction



Lesson 3: Solutions

Lesson 4: Projects


© SAP AG E2E200 2-71

© SAP AG 2007

SAP System Landscape Directory


System Catalog: Landscape Description

Physical View: Technical System

Logical View: Business System

Software Catalog: Component Information

Product

Software Component

SAP Systems Data Supplier

Registered automatically

Third PartySystems

Maintained at customer site

Third PartyProduct &Software

Component

Maintained at customer site

Maintained at SAP CIM

Update

MasterComponentRepository

Component Types

Landscape Patterns

Possible Combinations

At the SAP site, a Master Component Repository mirrors the data from the SAP Product and Production Management System (PPMS). Therefore, the Master Component Repository contains up-to-date information about all available SAP products and their dependencies.

The content of the Master Component Repository is published in the SAP Service Marketplace, so that customers can update their individual component information. The content updates are available as delta files.

Customers can add additional information, about 3rd-party products that they are using and their own development activities, to their individual component information in their own System Landscape Directories.

The landscape description contains information about all systems and installed products or components at the customer’s site.

Applications and tools (installation, administration etc.) use information from the System Landscape Directory as a central information provider.

Based on proven industry standards of the Distributed Management Task Force (DMTF): • Common Information Model (CIM) • Web-Based Enterprise Management (WBEM)

You can access SLD by directing a browser to http://<server>:<port>/sld (where <server> is the SLD server and <port> is the J2EE HTTP port). You will be prompted for a user name and password.

© SAP AG E2E200 2-72

© SAP AG 2007

Information Stored in SLD

Landscape Description

Technical Landscape

Landscapes

Business Landscape

Component Information

SLD is part of the J2EE Engine and can be reached using: http://<server_name>:<http_port>/sld

It contains the following parts: • Landscape Description • Technical Landscape • Business Landscape - Business Systems are logical systems that act as senders or receivers

within the SAP NetWeaver Exchange Infrastructure. A Business System is always associated with a technical system.

Component Information Name Reservation • Namespaces (done only by administrators) • Single names (done only by administrators – developers perform this task in the SAP

NetWeaver Developer Studio)

© SAP AG E2E200 2-73

© SAP AG 2007

Landscape Description

Installed systems with comprised products and componentsIncludes installed versions and patch levelsSystem topology information (addresses and links)Data by/for SAP NetWeaver Exchange Infrastructure (XI):

Application business system names Transport targets for directory content transportsSoftware component versions

© SAP AG E2E200 2-74

© SAP AG 2007

Component Information

Software catalog provides information about all available SAP software

Includes available version numbers and patch levels

Dependencies between componentsand other relations:

Supported platforms and releasesfor OS, DB, ....Allowed combinations (integrationmatrix – inter-productdependencies)

Data provided by SAP ( regular update from SAP Service Marketplace)

Basis for the description of the system landscape

Customers can download and update the current components description from the SAP Service Marketplace

At SAP, we use one common server with up-to-date information. Note 669669 describes how the Component Information can be updated.

© SAP AG E2E200 2-75

© SAP AG 2007

How Does SLD Get Landscape Description Data?

ABAPSystem

ABAPData

Supplier

JavaSystem

JavaData

Supplier

OtherSystem

OtherData

Supplier

sldreg(lib/exe)

Java System

SLD

RFC

HTTP

HTTPC

Gate-way

Data suppliers collect and send system data to SLD:Must be set up once per landscape elementAfter this, they send reliable and up-to-date data automatically:

At the system startup Periodical reporting (batch job)

Each SLD server contains an SLD data bridge, which is capable of sending system data received from the Data Supplies to multiple SLD servers.

The system information is reported periodically as well as at system startup. The data supplier within an ABAP-based system periodically delivers collected system

information to SAP Gateway (also required) Data suppliers are available for ABAP-based systems as of release 4.0B

(SAP_BASIS/SAP_ABA) SAP Gateway routes information to SLD bridge (part of SLD) SLD bridge transfers this information (as CIM-compliant data) to SLD

© SAP AG E2E200 2-76

© SAP AG 2007

Data Supplier – ABAP-Based Systems

Transaction RZ70

To set up an ABAP data supplier, you only have to call transaction RZ70 and specify the host and service name of the SAP Gateway. A batch job can also be set up so that the data supplier regularly sends its data to SLD. In this example, the data supplier sends its data every 12 hours (720 minutes) to the SLD gateway.

The data collection programs, in the lower part of the transactional screen, are normally only required for advanced users or by SAP support.

© SAP AG E2E200 2-77

© SAP AG 2007

Data Supplier – JAVA-Based Systems

The setup of a Java data supplier is similarly straightforward – in the J2EE Engine Visual Administrator (go.bat), choose Administration Server Services SLD Data Supplier and specify host, port, user and credentials of the SLD bridge to which you want to connect. You can also set up a batch job as in the ABAP case.

© SAP AG E2E200 2-78

© SAP AG 2007

SAP Solution Manager and System Landscape Directory

SAP SLD Server

SAP ABAP System

SLD

2. Specify service for communication

Configure the SLD Data Supplier


SMSY

1. Connect SLD to Solution Manager

3. Create TCP/IP connection

4. Schedule Periodic Data Transfer from SLD

Pull via RFC

Push via

RFC

Push via

http

SAP Java System

Configure the SLD Data Supplier

Pull via

RFC

SAP Solution Manager also provides a system data repository Both system data repositories can be used independently of each other A synchronization point exists. SMSY can read data from SLD

Use of these repositories depends upon current customer‘s landscape:

If there are only ABAP components in place SLD is optional If there are also Java components in place (SAP NetWeaver Enterprise Portal, SAP

NetWeaver Exchange Infrastructure, etc.) SLD is mandatory SLD Clients

Configure the SLD Data Supplier (in an ABAP system) Call transaction RZ70 and maintain the gateway server host and the name of the gateway service.

Configure the SLD Data Supplier (in a J2EE system) Start the J2EE Engine Visual Administrator and navigate to Administration → Server → Services → SLD Data Supplier.


Connect System Landscape Directory to Solution Manager (transaction SLDAPICUST). Create a TCP/IP connection to the SLD (SM59)

© SAP AG E2E200 2-79

For automatic data capturing, start the TX SMSY_SETUP and configure the sources System Landscape Directory with the time interval

© SAP AG E2E200 2-80

SLD Server: Activate the SLD Server Call up the SLD initial page http://<host>:<port>/sld and choose

Administration → Server Settings. Enter a name for the Object Server. Import the SAP Master Component information Choose Administration → Import and select

the file CR_content.zip Specify Service for Communication (JCo RFC Provider) From the J2EE side ,

/usr/sap/JCXX/J2EE/admin/go or go.bat, Visual admin—Server Services Jco RFC Provider (fill with the information shown on the screen)

© SAP AG E2E200 2-81

© SAP AG 2007

Establish Connection from SAP Solution Manager to SLD

The Implementation Guide for the SAP Solution Manager contains a step-by-step description of how to set up the connection from the SLD to SAP Solution Manager.

© SAP AG E2E200 2-82

© SAP AG 2007

Solution Manager

Managed Systems

SMSY LandScape model (ABAP)

Solution Manager - IT Governance –

(ABAP)

Solution Manager - Diagnostic –

(J2EE)

SMD LandScape model withembedded pseudo SLD (J2EE)

ABAP based component

J2EE based component

Unmanaged component(C/C++, Java standalone, …)

SLD Data Supplier (SLDREG)

SLD Data Supplier (J2EE)

SLD Data Supplier (ABAP)

CIM via RFC (push)CIM via HTTP (push)

RFC calls (push)

1

2

3

5

46

RFC calls (poll)

Managing System

Local SLD (J2EE)

Remote SLD (J2EE)

1

6

2 34 5

Landscape Modelling - Today

(1) ABAP based component pushes changes in deployment to SLD via CIM over RFC on a regular basis

(2) J2EE based component pushes changes in deployment to SLD via CIM over HTTP on a regular basis

(3) Unmanaged component (C/C++, Java Standalone, …) pushes changes in deployment to SLD via CIM over HTTP on a regular basis

(4) ABAP based components are polled on a regular basis to read deployment data and transfer to SMSY via RFC

(5) Remote SLD (or even several SLDs) is polled on a regular basis to read deployment data transfer to SMSY via RFC

(6) SMSY pushes deployment data for ABAP and non-ABAP components to SMD Landscape Model

© SAP AG E2E200 2-83

© SAP AG 2007

Landscape Modelling - Outlook

Solution Manager

Solution Manager - Diagnostic –

Solution Manager IT Governance –

Direct JAVA API calls (poll)Direct ABAP API calls (poll)

CIM via RFC / HTTP (push)SLD data via HTTP (push)

Managing system

Managed systems

ABAP based component

J2EE based component

Unmanaged component(C/C++, Java standalone, …)

SLD Data Supplier (SLDREG)

SLD Data Supplier (J2EE)

SLD Data Supplier (ABAP)

RemoteSLDLocal SLDSMSY

Unified SolMan landscape model

Regular data synchronizationfrom SLD to SMSY and back

1

2

3

54

Agent forNon-SAP

App(optional)

123

45

This figure shows how the SAP Solution Manager (SMSY) gets data from the System Landscape Directory (SLD) and vice-versa.

There is a local SLD on the SAP Solution Manager system which exchanges data with the SMSY.

If there are other SLDs in the system landscape they also exchange data with the local SLD on the SAP Solution Manager.

(1) Regular push of deployment changes to SLD for ABAP based component pushes via CIM over RFC and for all other components (J2EE, C/C++, Java Standalone, …) via CIM over HTTP

(2) Remote SLD‘s forward latest technical component-specific information to local SLD and store it in J2EE DB regularly or instantly (asynchronous).

(3) The SMSY polls local SLD to get latest landscape information (technical as well as logical) on a regular basis . After enrichment in SMSY, data is published from SMSY back to local SLD.

(4) All ABAP based SolMan apps read its landscape data from SMSY (as today) (5) All J2EE based SolMan apps read the landscape data from SLD (difference to today)

© SAP AG E2E200 2-84

© SAP AG 2007

Components using SLD

NWDI

PI/XI Web DynproSLD

NetWeaverAdministrator

Solution Manager

Adaptive Computing Controller

Information stored in SLD is essential to follow applications running in your production landscape: • SAP NetWeaver Exchange Infrastructure:

- Availability of SLD, is required at restart of SAP NetWeaver Exchange Infrastructure - As used SLD caches may be invalidated manually, SLD may also be critical during

runtime of SAP NetWeaver Exchange Infrastructure. • Web Dynpro of Java:

- SLD is critical during runtime for adaptive RFC calls • SAP NetWeaver Administrator:

- Requires SLD for remote monitoring functions - If SLD is unavailable, central administration of systems is not possible

• Adaptive Computing Controller: - Requires SLD to operate (that is, start, stop and change of resources) - If SLD is unavailable, only monitoring functions of Adaptive Computing Controller are

available

© SAP AG E2E200 2-85

© SAP AG 2007

Reasons to Have Several SLDs

Geographical distributed locations with local admin groups

Isolated production environment

Improve availability for applications relying on SLD data

…DEV CONS QA PRODFirewall

HQ

SAP NetWeaver

XI

WebDynpro

SAP NetWeaver

Admin.X7

24

There is no perfect strategy for setting up SLD in an SAP landscape. Several factors can influence your decision: • Organization, operation and security • Geographical situation of networks • Independent/Global Strategy • Subsequent separation of development and production environment • Usage of Components accessing SLD • Distribution of own Software Component Information

© SAP AG E2E200 2-86

© SAP AG 2007

Your SLD Topology – A Question of Your Requirements

Central – Single SLD Distributed – Several SLDs

Synchronization of several SLDs – Automatic Forwarding

Synchronization of several SLDs – Export/Import

ExtranetIntranet

I nt r anet

SLD

Intranet

Hosting Provider

Customer 1

SLD SLD

SLD

Automatic forwarding

of landscape

data

Extranet (World Wide Company Network)

Region 1

SLD SLD

Automatic forwarding

of landscape

data

Extranet (World Wide Company Network)Region 1

Export and import of SLD data

Org

aniz

atio

nS

ynch

roni

zati

onSAP

System

SAPSystem

SAPSystem SAP

System

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SAPSystem

Customer 2

SAPSystem

Region 2

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SLD

Region 2

SAPSystem

SLD

SAPSystem

SAPSystem

The simplest way is to have only one SLD for your landscape. The cost of running an SLD infrastructure increases with the number of SLD instances, as several SLDs have to be administrated (for example, CR Content has to be updated regularly). Depending on your requirements, you also have to think about synchronization of SLD data stored in different SLDs: • The SLD bridge can automatically forward data received by data suppliers to additional

SLDs • Data entered manually into one SLD (such as XI business systems, name reservation data,

products/software components, etc.) has to be synchronized manually with export/import functions of SLD.

Requirements/reasons to have more than one SLD in your landscape, for example: • Legal constraints • Company rules • Network constraints (such as firewalls) • Availability • Possibility to provide different views of SLD data (for example, you want that DEV

systems/admins are not able to see/access PROD system data)

© SAP AG E2E200 2-87

All together, it depends on the actual requirements of a landscape (what data is required in which SLD, how often is a manual synchronization required, etc.) to decide what is the optimal SLD landscape.

For more information, see the Planning Guide – SLD (available in SAP Service Marketplace at service.sap.com/sld)

Note 764393 describes different SLD topologies.

© SAP AG E2E200 2-88

© SAP AG 2007

Distribution of Component Information

SAP MasterComponent Information

Customer/3rd Party ComponentInformation

SLD

All Comp. Information

Export

SLD

SLD

SLD

Import

Import

Import

The synchronization of SLD content (business systems, SWCV, transport groups and transport targets) is mandatory to use the transport functionality of the Integration Directory.

SLD Export/Import functionality is available to distribute SLD content between multiple SLDs. • With multiple SLD systems and customer defined software components import the CR data

provided by SAP into one system only and distribute it from there. • To distribute CR data in your system landscape, use the export line CR exports. These

exports contain all CR data from the export system, regardless of whether the data was created by the user or by SAP.

© SAP AG E2E200 2-89

© SAP AG 2007

Export SLD Content

SLD Content can be exported/imported:CR: Component InformationLD: Landscape DescriptionNR: Namespace Reservation

After clicking Export, the page will be refreshed automatically after a successful export The exported .zip file can be downloaded from the refreshed page

© SAP AG E2E200 2-90

© SAP AG 2007

Example of a Distributed Environment

Development QASPre-Prod Prod

SLD

SLD

SLD

SLD SLD

SLD

SLD

PI

PIPI

PI PI

PI

PIPI

PI

PIPI

PI

Cor

pora

te D

evel

opm

ent

Euro

peAs

iaA

mer

icas

Transport SLD Content by Export / Import

This figure shows the PI / SLD landscape in a distributed environment. There is a central development area, in which the Development and Quality Assurance

systems are located. These systems share a common SLD. In this SLD, Software Components and Namespaces for Java Development are defined. SAP content is imported into this SLD. All information from this SLD is imported and exported into the SLDs in the Preproduction and Production Environment.

Due to high availability requirements, each PI system in the Production environment has its own local SLD. The Preproduction environment is built up in the same way as the production environment.

The SLDs in the Development, QAS and Preprod environment have no information about productive systems. Therefore the productive systems cannot be called up accidently during the test phase.

© SAP AG E2E200 2-91

© SAP AG 2007

Exercise

Exercise

© SAP AG E2E200 2-92

© SAP AG 2007

Training Systems

Web AS Java

RDBMS

Portal Platform

Content Management &

BP for MSS

Front End PC

Adobe DocumentServices 1.0Web Browser

SAP ECC

Web AS ABAP

Client 800

SAP EP

JCO

TT5, hostname: ________

Network

Web AS Java

RDBMS

Content Management &

BP for ESS

BP for MSS

SAP XSS 6.0


Web AS ABAP

Instance: 00


DiagnosticsJCO

TT4, hostname: ________Adobe Document

Services 1.0SAP GUI

http://<hostname>:55000/sld

http://<hostname>:55000/irj

http://<hostname>:50000/smd

SLD

Client 200

Instance: 50

TT5 is a mySAP ERP 2005 system. TT4 is a Solution Manager 4.0 system. The Enterprise Portal and the System Landscape Directory are located on the mySAP ERP

2005 system TT5. The default port is 5<Instance number>00. The Solution Manager Diagnostics is located on TT4.

© SAP AG E2E200 2-93

© SAP AG 2007

Solution Manager Unit Overview Diagram




Lesson 3: Solutions

Lesson 4: Projects


© SAP AG E2E200 2-94

© SAP AG 2007


Solution Directory

Systems

NWBI

Other

BusinessProcesses

Documentation

SAPERP

NWXI

Projects

Solution


Service Desk


Testing


Implemen-tation

ContentBPR

Application Manage-

ment



© SAP AG E2E200 2-95

© SAP AG 2007

Systems Software-Components

Solution MonitoringService Desk

Change Request ManagementCollaboration

Scenarios

Solution

Solution Definition

A solution describes a collection of information about systems, software components, and business processes (scenarios).

Solutions are the basis for the operation scenarios • Solution Monitoring • Service Desk • Change Request Management • Collaboration

Solutions provides handover information from the project phase to the operations phase • Any project change is copied to the solution directory after being set active

© SAP AG E2E200 2-96

© SAP AG 2007

Europe ERP

Europe CRM

Europe Solution

Asia ERP

Asia CRM

Asia Solution

US ERP

US CRM

US Solution

Global BW

Example: Design of Solutions by Regions

In this example the solutions are separated by regions. The global BW system is part of all solutions

© SAP AG E2E200 2-97

© SAP AG 2007

Gobal ERP

Global CRM

Financial Solution

Global BW

Example: Design of Solutions by Functional Areas

Gobal ERP

Global CRM

Logistics Solution

Global BW

Gobal ERP

Global CRM

HR Solution

Global BW

In this example the solutions are separated by functional areas. All systems are part of all solutions, but different business processes are running in each

Solution.

© SAP AG E2E200 2-98

© SAP AG 2007

Criteria for Tailoring a Solution

Business Processes must run in only one solution (most important criterion)

All systems involved in a business process belong to the same solution

The number of systems in the Solution should be limitedThere is no strict limit, but the number of systems should be limited due to performance and usability aspectsThe performance is driven by the number of monitoring alerts that need to be processed in a certain time period

Organizational units of a company or a corporate groupAre different organizations supporting different system groups?Is it necessary to restrict authorization to monitoring and functional data to certain system groups?Does a hosting provider support different companies?

Normally small and medium size customers may use only one Solution!

From SAP’s point of view, the critical drivers for tailoring a solution are the size of the documented end-to end business processes, as well as the related number of systems involved, depending on use, for example, system monitoring.

For complex organizations, we recommend that you define several solutions in accordance with the organizational tailoring and the selection requirements of the individual organizational units. In this way, large and complex customers and corporate groups can be displayed more clearly in special sections and administrated more effectively. However, it is essential that all of the business objects for a business process are located within one solution. The process must not be divided among several solutions or sub processes.

© SAP AG E2E200 2-99

© SAP AG 2007

Solution Overview

Transaction SOLUTION_MANAGER is the central access point for all operation scenarios in the SAP Solution Manager

The Solution Directory is the central point for maintaining business processes in SAP Solution Manager. Here, you can assign logical components to your solution landscape, create business processes and copy business processes from implementation projects or other sources. You can also maintain your solution settings, like the name of the solution, here.

© SAP AG E2E200 2-100

© SAP AG 2007

Assignment of Logical Components to the Solution

Choose node <solution name>.

Assign logical components in tab

“System Group” via value help.

Business Processes are executed on logical components. Before you can maintain a business process you therefore have to assign the concerned logical components to the solution landscape.

In the node <solution name> you can also change the solution settings (tab “Solution Settings”), for example, what day of the week the Early Watch Alert data is supposed to be processed and for what systems the EWA should be processed within this solution.

© SAP AG E2E200 2-101

© SAP AG 2007

Assignment of Business Processes in the Solution Directory

Business processes can be created manually, copied from a business process repository, from other solutions or from projects.

The data is displayed in a “swim-lane” graphic (as it is used also in the project maintenance) indicating on which logical component the business process step is executed.

© SAP AG E2E200 2-102

© SAP AG 2007

Link Maintenance Project to a Solution

As of SAP Solution Manager 4.0 you can link a Maintenance Project to a Solution.

This enables you to:Check-out/Check-in Solution Structure ElementsCreate Change Requests for a Solution

In SAP Solution Manager 4.0, it is possible to link a Maintenance Project to a solution. For example, once a solution is handed over to the Operations functions for production support, it may be necessary to make changes to the process structure, linked documents or configuration objects. These items may now be “checked out” to the linked Maintenance Project where they can be changed and documented. After work is completed and approved these changes may be “checked in” to the solution. In this way the solution can be updated in an efficient and documented manner.

© SAP AG E2E200 2-103

© SAP AG 2007

Scenario Checked Out

In this example the Business Scenario Order to Cash is checked out, and can be maintained in the linked maintenance project.

© SAP AG E2E200 2-104

© SAP AG 2007





Lesson 3: Solutions

Lesson 4: Projects


© SAP AG E2E200 2-105

© SAP AG 2007


Solution Directory

Projects

Solution


Service Desk


Testing


Application Manage-

ment

Systems

NWBI

Other

BusinessProcesses

Documentation

SAPERP

NWXI

Implemen-tation

ContentBPR



© SAP AG E2E200 2-106

© SAP AG 2007

Solution Manager Projects

Projects:Projects focus on managing changesAll implementation scenarios in SAP Solution Manager are based on projects:

ImplementationTestingUpgradeE-Learning Management

Any project change is copied to the solution directory after being set active

Handover to OperationProjects work not only in the production landscape, but in the complete transport landscapce including the following system types:

EvaluationDevelopment Quality Assurance…

© SAP AG E2E200 2-107

© SAP AG 2007

Scope of Projects

Gobal ERP

Global CRM

Development

Global BW

Gobal ERP

Global CRM

Quality Assurance

Global BW

Gobal ERP

Global CRM

Production

Global BW

Project Land-scape

Solution

Project Phases

RealizationFinal

Preparation Go Live

In this example, the project works on the ERP and CRM system. The complete transport landscape is part of the project.

© SAP AG E2E200 2-108

© SAP AG 2007

ImplementationProject

Solution 1

Solution 2

Solution 3bSolution 3a

UpgradeProject

TemplateProject

Solution 1 MaintenanceProject



Implementation

Operation

Upgrade

Rollout

Lifecylce Management is performed within Projects

Solutions represent a productive system landscape. Changes to a solution are managed in projects. The following types of projects exist: • Implementation

- Used for implementation projects • Template

- Create templates and re-use them in implementation projects • Upgrade

- Used for upgrade projects • Maintenance

- Used for change request management • Optimization / Safeguarding

- Used for SAP Optimization and Safeguarding Services

© SAP AG E2E200 2-109

© SAP AG 2007

General Project Administration

General project administration functions:Transaction SOLAR_PROJECT_ADMIN Create projectsChange projectsDisplay projectsDelete projects Transport projectsDirect access to project templates

Any existing projects are displayed in the project overview of Solution Manager. Additional functions are available to coordinate the project administration data of a project. Transaction SOLAR_PROJECT_ADMIN provides an overview of the active projects in the

customer organization.

© SAP AG E2E200 2-110

© SAP AG 2007

Define Project – General Data

Define general project data:Person responsible for the projectLanguage of the project: determines in which language the selected business content is displayed and storedOverall project statusProject time frame for plan and actual data

You can enter the following data on the General Data tab: Person responsible - The responsible person must exist in the project administration of the

SAP System. You can use the possible entries help to change the responsible person. Project language • When you choose a project language, all language-dependent information for this language

(project documentation and status information) is made available to project members. This is independent of the logon language of the project member.

• The project structure is created in the specified project language. • All content will be stored in the chosen project language. • Once the project language has been selected and saved, it can no longer be changed.

Status - The default values for status are set on the Project Standards tab. Plan Data - This tab allows you to enter the dates for the planned project start and finish as

well as the work required in man days (MD). Actual Data - This tab allows you to enter the dates of the actual project start and finish and

the actual work carried out in man days (MD). • The planned data and the actual data represent the time plan for the entire project. Any

dates entered for individual process steps in the Business Blueprint or Realization phases must lie within the time frame set on the General Data tab.

© SAP AG E2E200 2-111

© SAP AG 2007

Define system landscape for a project:Select product and product version Assign development, quality assurance and productive systems to productsCheck related system landscape

Assign Logical Components

Transaction => Project Administration / SOLAR_PROJECT_ADMIN You define the system landscape for a template or implementation project in this tab. A system landscape for project consists of the following information: • Logical component • Product version • Logical systems for dedicated system roles

In Business Blueprint, the system role Evaluation may be maintained to test-drive related transactions of process steps. You can add systems for other system roles during the course of the project.

You cannot maintain the logical system information for non-SAP products. Maintaining logical components: • A logical component reflects a set of logical systems (instances) for a product. In case you

have to handle mulitple instances of systems for a product, you need to create additional logical components

• The selection of the logical component influences the scenarios/processes selection using the Business Process Repository in phase Business Blueprint. Only those scenarios/processes that are complient to defined logical component and product version are released for selection.

© SAP AG E2E200 2-112

© SAP AG 2007





Lesson 3: Solutions

Lesson 4: Projects


© SAP AG E2E200 2-113

© SAP AG 2007

Business Processes in SAP Solution Manager

Scenario

Business Process 1

Business Process 2

Process Step 1

Process Step 2

...

Process Step 1

...

Component View

VISUALIZE flow of business processes and process steps

Show components required by business scenario or process

Show business partners or external software required by the business scenario or process

Tra nsfer Cam paig n, Targ et Gr oup, Products, Att ach ments, A ll oc. to Mobile

CRM MOBI LE C LIENT

Tra nsfer Acti vities to CRM Mobil e

Refere nce t o Busin ess Pro cess: Custom er V isit a nd O rde r Entry

CRM SERVER

Create Cam paig n

Refere nce t o Busin ess Pro cess: Tar get Gr oup Cre ation

Create Collat era ls

Allocate t o cam paig n

P lan Key Figu res

P lan A llocati ons

Releas e Ca mpai gn

Tra nsfer Cam paig n

Tra nsfer Ta rget Gro ups

Execute C amp aign

Refere nce t o Busin ess Pro cess: Lead P roces sing

Refere nce t o Busin ess Pro cess: Order P roces s in B2B eS ellin g

Refere nce t o Busin ess Pro cess: Order P roces s in B2C eSellin g

SAP R/3

Create Accou nting Object (WBS)

Post Direct Mark etin g Costs t o Accountin g Obj ect (WBS)

Settle Dir ect Ma rketi ng Co sts to Profitabilit y Seg ment

Load Cost Dr ivers

Assess Over hea d Cost s to WBS Element

SAP SEM

Perfor m Ma rket An alysis

Updat e the C am paig n Hier arc hy

Load Cam paig n Attrib utes

Updat e the K ey Fi gur es for the Camp aign

Load All ocati ons

Updat e Direc t Ma rketin g Cost s Info

Updat e Activities I nfo

Updat e Over hea d Cost s Info

Perfor m Cam pai gn Ana lysis Scenario-oriented structure (= Business Process Hierarchy)

Definition of the Business Blueprint allows you to document the business processes, in your enterprise, that you want to use in your SAP System. You create a project structure in which relevant business scenarios, business processes and process steps are organized in a hierarchical structure. You can also create project documentation to assign to individual scenarios, processes or process steps. To define how your business processes should run in your SAP Systems, you then assign transactions to each process step.

Definition of the Business Blueprint provides you with a detailed description of your business processes and system requirements. You can also print out the Business Blueprint document. The project documentation and the project structure that you use during the Business Blueprint phase, can also be put to further use during configuration and test organization. • When you configure your business processes, the system displays the project structure you

created for the Business Blueprint. You can use the Business Blueprint project structure as an orientation point during configuration.

• You can also display and edit the project documentation from the Business Blueprint phase during configuration.

• The project structure from the Business Blueprint forms the basis for all test plans that you create during test organization. The transactions that you assign to process steps in the Business Blueprint are put in test plans during test plan generation. The transactions can be processed as function tests to test the transactions.

© SAP AG E2E200 2-114

© SAP AG 2007

Business Process Structure

Documentation linked to business

process steps

The Business Process Structure is the central documentation directory. Different types of documentation can be attached to business processes or business process

steps. Documentation can be: • General project documentation • Transactions to be used • Configuration Information • Development Documentation • Test Cases • Training Material

Documentation which is entered in SAP Solution Manager is available to all involved parties. The documentation can be re-used in later project phases, e.g. in testing or during the end-user

training

© SAP AG E2E200 2-115

© SAP AG 2007

Copy Business Processes from Project to Solution

Create business processes.

Set status to “Production”.

For each business scenario, create the respective business processes. Choose <solution name> / Business Scenarios / <scenario name> / Business Processes in the tree and create the business processes in tab “Structure”.

Business Processes are attached to either a project or a solution. Business Processes can be copied from a project to a solution when a project goes live. Set the status for the business process to “Production” if you want to monitor the business

process. This is only possible if there is a production system assigned to the logical components that the business process is using.

© SAP AG E2E200 2-116

© SAP AG 2007

SAP Solution Manager Introduction: Unit Summary

You should now be able to:Explain the Architecture and Use Cases of the Solution Manager System Landscape

Keep the Solution Landscape Documentation up to date by using automatic data collection procedures within SAP Solution Manager and System Landscape Directory

Define and tailor Solutions to manage productive systems

Use Solution Manager Projects to manage complex implementation projects

Document business processes in the SAP Solution Manager

© SAP AG E2E200 2-117

© SAP AG 2007

Additional Information

Self Study – Learning Maps for SAP Solution Manager:service.sap.com/rkt-solman

For more information, refer to the SAP Service Marketplace:service.sap.com/solutionmanager

In the SAP Community Network a Discussion Forum on SAP Solution Manager is available: www.sdn.sap.comForum SAP Solutions SAP Solution Manager

© SAP AG E2E200 2-118

Exercises

Unit: Solution Landscape Documentation Lesson: Solution Manager System Landscape

At the conclusion of this exercise, you will be able to: • Find version information for a customer solution in SAP Solution

Manager

TT4 is the Solution Manger system which contains all information about the system landscape. TT5 is a satellite system which is managed by TT4.

2-1 Check the support package level in the SAP Solution Manager System TT4

2-1-1 Name the transaction to find the system landscape description in SAP Solution Manager: Answer: ______________________________________________

2-1-2 Call transaction SMSY and find information for the SAP ECC System TT5. What is the current Support Package Level for the software component SAP_APPL? Answer: ______________________________________________ What is the data source of the version information? Answer: ______________________________________________ When was the data last refreshed? Answer: ______________________________________________

© SAP AG E2E200 2-119

2-1-3 Find version information for the Enterprise Portal on TT5 (SAP Netweaver TT5_X). What is the current Support Package Level for the software component CORE-TOOLS? Answer: ______________________________________________ What is the data source of the version information? Answer: ______________________________________________ When was the data last refreshed? Answer: ______________________________________________

© SAP AG E2E200 2-120

Exercises

Unit: Solution Landscape Documentation Lesson: System Landscape Directory

At the conclusion of this exercise, you will be able to: • Find version information for a customer solution in the System

Landscape Directory


2-2 Logon to the System Landscape Directory of TT5 and perform the following

analyses. 2-2-1 How can you logon to the SLD? 2-2-2 Click on Technical Systems and search for all technical systems of type

“Web AS Java”. 2-2-3 What is the current support package for the software component version

“J2EE Engine Core Tools 7.00” of this system?

Answer: ______________________________________________ 2-2-4 What is the lastest Support Package available for this component?

Answer: ______________________________________________ 2- 2-5 Where does the information on the latest Support Package come from?

Answer: ______________________________________________ 2-2-6 Is a business system defined?

© SAP AG E2E200 2-122

Exercises

Unit: Solution Landscape Documentation Lesson: Solutions

At the conclusion of this exercise, you will be able to: • Create a solution landscape in SAP Solution Manager • Navigate in SAP Solution Manager

This exercise has to be executed in the Solution Manager system TT4. The solution consists of the mySAP ERP system TT5, an Enterprise Portal system, a CRM system and an XI system.

2-3 Create a Solution

2-3-1 Name two transactions to call the operations part of SAP Solution Manager: Answer: ______________________________________________

2-3-2 Copy Solution Landscape E2ECC Demo Solution in the operations part of your SAP Solution Manager to a new solution with the following data: • Solution Name E2ECC_## (## = your group number) • Select Copy existingEarly Watch, …

2-3-3 Navigate into Solution Landscape Maintenance of your solution. Which logical components are assigned to your solution? Answer: ______________________________________________

2-3-4 Navigate to the Business Scenarios area in the Solution Landscape Maintenance part of your solution. Which business scenarios and business processes are assigned to your solution? Business Scenarios: ___________________________________________ Business Processes: ___________________________________________

2-3-5 Display the graphic of the business process Sales Order Management.

© SAP AG E2E200 2-124

Exercises

Unit: Solution Landscape Documentation Lesson: Projects

At the conclusion of this exercise, you will be able to: • Create a project in SAP Solution Manager • Maintain project data

This exercise has to be executed in the Solution Manager system TT4. The project consists of the mySAP ERP system TT5, an Enterprise Portal system, a CRM system and an XI system.

2-4 Create a project

2-4-1 Name the transaction in SAP Solution Manager to create a project Answer: _________________________________________________

2-4-2 Create a new project with the name E2ECC_## of type Maintenance. Do not assign a solution. Enter a title for the project and select the project language English.

2-4-3 In the folder System Landscape enter the same logical components that were assigned to the solution in the last exercise.

© SAP AG E2E200 2-126

Exercises

Unit: Solution Landscape Documentation Lesson: Business Processes Optional Exercise

At the conclusion of this exercise, you will be able to: • Assign maintenance projects to solutions • Check out business processes from solutions into projects • Maintain business processes

This exercise has to be executed in the Solution Manager system TT4. The business process runs within a SAP ECC system, an Enterprise Portal system and a CRM system

2-5 Check out a business process and maintain it in a project

2-5-1 Go to the solution that you have created in the exercise before. Assign a maintenance project to the solution.

2-5-2 Enable Check-out / Check-in of Solution Structure Elements. 2-5-3 Check out the business process Sales Order Management 2-5-4 The business process can now be maintained in the maintenance project

which is assigned to your solution. Name the transaction for maintaining the business blueprint in a project? Answer: _______________________________________________

2-5-5 Go to transaction SOLAR01 and add an additional step to the business process. Call the business process repository and select the business scenario Logistics and the business process step Order Generation.

2-5-6 Check in the business process Sales Order Management back to the solution.

2-5-7 Is it still possible to maintain the business process in the project after it is checked in back to a solution? Answer: ________________________________________________

© SAP AG E2E200 2-128

Solutions

Unit: Solution Landscape Documentation Lesson: Solution Manager System Landscape

2-1 Check the support package level in the SAP Solution Manager System TT4

2-1-1 Name the transaction to find the system landscape description in SAP Solution Manager: The transaction name is SMSY

2-1-2 Call transaction SMSY and find information for the SAP ECC System TT5. What is the current Support Package Level for the software component SAP_APPL? In the tree structure on the left hand side of transaction SMSY drill down into Landscape Components Systems SAP ECC TT5 SAP ECC Server. On the right hand side click on the tab Software Components. Search for the software component SAP_APPL and check the SP Level. What is the data source of the version information? Click on the tab Header Data and check the value for Data Source When was the data last refreshed? check the value for Last Changed On/By

2-1-3 Find version information for the Enterprise Portal on TT5 (SAP Netweaver TT5_X). What is the current Support Package Level for the software component CORE-TOOLS? In the tree structure on the left hand side of transaction SMSY drill down into Landscape Components SAP Netweaver TT5_X Enterprise Portal. On the right hand side click on the tab Software Components. Search for the software component CORE-TOOLS and check the SP Level. What is the data source of the version information?

© SAP AG E2E200 2-129

Click on the tab Header Data and check the value for Data Source When was the data last refreshed? check the value for Last Changed On/By

© SAP AG E2E200 2-131

Solutions

Unit: Solution Landscape Documentation Lesson: System Landscape Directory

2-2 Logon to the System Landscape Directory of TT5 and perform the following

analyses. 2-2-1 How can you logon to the SLD?

Use the URL http://<hostname>:<port>/sld and provide a username and password in order to logon to the SLD. The default port is 5<instance>00. Hostname, username and password will be provided during the training.

2-2-2 Click on Technical Systems and search for all technical systems of type Web AS Java In the Home screen of the SLD click on the link Technical Systems. Choose the technical system type Web AS Java.

2-2-3 What is the current support package for the software component version “J2EE Engine Core Tools 7.00” of this system? Mark the system TT5 which sent updates to the SLD most recently. In the lower part of the screen click on the folder Installed Products. Click the button Filter On and enter the filter “J2EE ENGINE CORE TOOLS 7.00” for the column Software Component Versions and hit Enter. Write down the current Support Package Level.

2-2-4 What is the lastest Support Package available for this component? Write down the latest available Support Package Level.

2-2-5 Where does the information on the latest Support Package Level come from? A file with the latest component repository information can be downloaded from the SAP Service Marketplace and imported into the SLD. This file contains information on available software components and support package level. It must be imported into the SLD regularly. See SAP Note 669669.

2-2-6 Is a business system defined?

© SAP AG E2E200 2-133

Solutions

Unit: Solution Landscape Documentation Lesson: Solutions

2-3 Create a Solution

2-3-1 Name two transactions to call the operations part of SAP Solution Manager: Answer: DSWP, SOLUTION_MANAGER

2-3-2 Copy Solution Landscape E2ECC Demo Solution in the operations part of your SAP Solution Manager to a new solution with the following data: • Solution Name E2ECC_## (## = your group number) • Select Copy existingEarly Watch, …

Call /nDSWP. In the solution overview mark solution E2ECC Demo Solution and choose copy. In the subsequent screen enter the name E2ECC_## and mark Copy existing EarlyWatch, …. Then choose Copy Solution

2-3-3 Navigate into “Solution Landscape Maintenance” of your solution. Which logical components are assigned to your solution? Choose the name of your solution in the solution overview. Then, go to Operations Setup -> Solution Landscape Maintenance The logical components are:

- Z_E2ECC_ECC - Z_E2ECC_CRM - Z_E2ECC_EP

2-3-4 Navigate to the Business Scenarios area in the Solution Landscape Maintenance part of your solution. Which business scenarios and business processes are assigned to your solution? In the Solution Structure on the left hand side drill down into Business Scenarios Sales Business Processes Sales Order Management The Business Scenarios are: Sales The Business Processes are: Sales Order Management

2-3-5 Display the graphic of the business process Sales Order Management The result should look like this:

© SAP AG E2E200 2-135

Solutions

Unit: Solution Landscape Documentation Lesson: Projects

2-4 Create a project

2-4-1 Name the transaction in SAP Solution Manager to create a project Answer: SOLAR_PROJECT_ADMIN

2-4-2 Create a new project with the name E2ECC_## of type Maintenance. Do not assign a solution. Enter a title for the project and select the project language English. In transaction SOLAR_PROJECT_ADMIN create a new project. Enter the project name E2ECC_## and the project type Maintenance. Do not assign a solution. In the next screen enter a title for the project and select the project language English.

2-4-3 In the folder System Landscape enter the same logical components that were assigned to the solution in the last exercise. Goto the folder System Landscapes Systems and enter the following logical components with the F4 help:

- SAP ECC ECC Server Z_E2ECC_ECC - SAP CRM CRM Server Z_E2ECC_CRM - SAP NetWeaver Enterprise Portal Z_E2ECC_EP

© SAP AG E2E200 2-137

Solutions

Unit: Solution Landscape Documentation Lesson: Business Processes

2-5 Check out a business process and maintain it in a project

2-5-1 Goto the solution that you have created in the exercise before. Assign a maintenance project to the solution. In transaction DSWP select your solution and goto Operations Setup

Solution Landscape Solution Landscape Maintenance. In the Solution Structure mark the name of the solution and select the folder Solution Settings on the right hand side. In the area Assigned Maintenance Project press the button Assign and select the maintenance project that you have created before.

2-5-2 Enable Check-out / Check-in of Solution Structure Elements. Mark the check-box Enable Check-out / Check-in of Solution Structure Elements on the same screen

2-5-3 Check out the business process Sales Order Management. In the Solution Structure navigate into the business processes and mark Sales Order Management. On the right hand side of the screen click the button Request Check-out. Now the Check-out status is Check-out requested. Press the button Check out the object. The Check-out status is now Checked out.

2-5-4 The business process can now be maintained in the maintenance project which is assigned to your solution. Name the transaction for maintaining the business blueprint in a project: Answer: The transaction is SOLAR01

2-5-5 Goto transaction SOLAR01 and add an additional step to the business process. Call the business process repository and select the business scenario Logistics and the business process step Order Generation. Call transaction SOLAR01 and check in the title of the transaction that you are working in the right project. The business process Sales Order Management should now be seen in the business blueprint. In the Business Blueprint Structure on the left hand side mark the business process Sales Order Management. On the right hand side click on the folder Structure. You see the list of business process steps.

© SAP AG E2E200 2-138

Position the cursor at the end of that list and select the F4-help in order to go to the Business Process Repository. See the following screenshot:

In the Business Process Repository select the following business process step: Logistics Order Generation Generate Orders SAP ECC 6.0 Assign the logical component Z_E2ECC_ECC to the business process step and save your work.

2-5-6 Check in the business process Sales Order Management back to the solution. In the business blueprint mark the business process Sales Order Management. On the right hand side click on the button Check-in request close to the Check-Out status. The Check-out status is now Check-In Requested Go back to the Operations Setup of the solution and mark the business process Sales Order Management. Press the button Check in

2-5-7 Is it still possible to maintain the business process in the project after it is checked-in back to the solution? No the business scenario Sales is no longer assigned to the maintenance project.

© SAP AG E2E200 3-139

© SAP AG 2007






E2E Change Diagnostics

© SAP AG E2E200 3-140

© SAP AG 2007

Contents:

Configuration and File Reporting

E2E Change Analysis


© SAP AG E2E200 3-141

© SAP AG 2007

End to End Change Diagnostics: Unit Objectives

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

Look up recent changes in the customer solutionsincluding:



Content (EP, XI, BI, SLD, …)

Coding

Compare Technical Configuration between landscapes

© SAP AG E2E200 3-142

© SAP AG 2007

Change Diagnostics – Typical Questions

Is there ONE place where all changes in the

solution are listed

Did we changeany technicalconfigurationparameters?

How manytransports were

imported last week?

When did weimport support

packages?

Did we changeanything last

Tuesday?

Change Diagnostics supports customers in identifying, controlling, maintaining and verifying the versions of configurations and the values of parameters of the solution landscape components. Accurate information about configurations and their documentation is necessary to support auditing requirements and other solution operations processes. To track changes, the configuration information is recorded regularly inside the components and collected centrally in the SAP Solution Manger database. The configuration can be compared to a template or master configuration to analyze changes. The reporting includes all current and historical configuration data throughout the application life cycle. Together with Change Request Management and Change Deployment, Change Diagnostics supports the transition from project to operations and the management of code and configuration freeze phases.

© SAP AG E2E200 3-143

© SAP AG 2007

E2E Change Diagnostics: Overview



“Content”EP, XI, BI, SLD

CodingPatches, SP,Release

Productive Environment

Documented in SAP Solution Manager (SMSY)

Type of changes

Changes toProduction

Enhanced Change and Transport SystemConfiguration Tracking

Tools

E2E Change Analysis

This figure shows the different tools in E2E Change Diagnostics. Configuration Tracking extracts a configuration parameter from Java or ABAP based systems

and displays the parameter and their history in Solution Manager Diagnostics The Change and Transport System records changes to Business Configuration (Customizing

Requests) and Coding (Workbench Requests). The new Enhanced Change and Transport System is also able to transport Non-ABAP objects like Java archives.

Releases, Support Packages and Patches are documented in the SAP Solution Manager (SMSY).

E2E Change Analysis provides a BI based reporting on all changes in a solution.

© SAP AG E2E200 3-144

© SAP AG 2007

E2E Change Diagnostics: Benefits

Change Diagnostics supports customers in identifying, controlling, maintaining and verifying the versions of Configurations (e.g. OS/DB,SAP NetWeaver, Application, Customer Coding)

Benefits of E2E Change Diagnostics: Central entry point for analyzing changes in a solution BI methods to drill down from overviews to detailed lists of changesProviding hints for root cause analysis with data and trendsProviding accurate information on configuration parameters and their history (e.g. database parameters, ABAP parameters, JAVA parameters)Enabling the organization to standardize the solution configurationImproving security by controlling the versions of configurationsin use

© SAP AG E2E200 3-145

© SAP AG 2007

E2E Change Diagnostics Unit Overview Diagram

Lesson 2: E2E Change Analysis


Lesson 1: Configuration and File Reporting

© SAP AG E2E200 3-146

© SAP AG 2007

Web AS Instance

Web AS Instance

Web AS Instance

D

S S S

D

S S S

D

S S S

Agent Agent Agent

Web AS Instance

Web AS Instance

Web AS Instance

D

S S S

D

S S S

D

S S S

Agent Agent Agent

Web AS Instance

Web AS Instance

Web AS Instance

D

S S S

D

S S S

D

S S S

Agent Agent Agent


Configstore

Production

QA

Development

Architecture of a J2EE System Landscape

Here you see a J2EE system landscape with development, QA, and production systems. • Each system consists of one or several hosts. • Each host consists of one or several instances. • Each instance consists of several nodes (dispatcher, server, and so on).

A diagnostics agent is located on each host. It transfers configuration data to Solution Manager diagnostics once per day.

The need to track configuration settings first came up in J2EE systems. J2EE systems have a large number of configuration parameters in different locations. In the early days, it was difficult to track changes or to keep the configuration parameters homogeneous within the solution landscape.

© SAP AG E2E200 3-147

© SAP AG 2007

View Configuration Data

Configuration Change Reporting collects the configuration settings for all non-ABAP components in the customer solution and provides navigation via landscape trees to each configuration setting in the SMD. A history of changes is provided per single configuration setting (based on daily snapshots). In addition it is possible to display the configuration as it was at a given point in time. It also allows you to compare the configuration settings between two components within any landscape, at any given point in time. As a result, all the differences are highlighted.

Configuration and File Reporting is integrated into the Solution Manager Diagnostics. Select Root Cause Analysis Configuration Configuration and File Reporting to start the application.

© SAP AG E2E200 3-148

© SAP AG 2007

2.Click

Result

Compare two Landscapes

1.Click

3.Click

Compare two landscapes or two snapshots of the same landscape : Choose the desired timestamp and Click on the button “Compare” Select the appropriate landscape in the drop-down list “Landscape2”. Choose the desired timestamp for the landscape2. Check the node to compare (e.g.: Landscape, NW, SAP J2EE Engineer, Enterprise Portal). Click on the “Compare” button. If you select a node other than the Landscape, you need to

select the item to compare in lanscape2 in a pop-up window after you click the compare. Expand the configuration hierarchy to compare the attribute values.

The procedure for comparing two snapshots of the same landscape is similar to that outlined

above.

© SAP AG E2E200 3-149

© SAP AG 2007

Missing value

Unchanged value

Different value

Additional value

Compare two Landscapes - Result

In the result screen, you can drill down into the system parameters. You see different icons for unchanged values, different values, additional values and missing values.

© SAP AG E2E200 3-150

© SAP AG 2007

Compare Multiple Instances

Missingvalue

Additionalvalue

Unchanged value

Different value

Additional value

Missing value

The function “Compare Multiple Instances reduces the effort spent on comparing multiple J2EE Nodes and complex J2EE landscapes in the background.

You can compare different nodes on the same host or nodes on different instances and different hosts

A history of changes is provided for each configuration parameter (based on daily snapshots). In addition, it is possible to display the configuration for a given point in time

It enables the organization to standardize the solution configuration The use case “Compare Multiple Instances” is very useful to: compare different instances among different hosts (clustered environment) compare different instances from different landscapes (eg: PROD vs, QAS, DEV, TEST)

Procedure:

Navigate to Compare Multiple Instances ->Trigger compare tab Check two or more instances to compare Select one instance as the main instance. This will be used as reference. All other instances are

compared with the main instance. Trigger the compare (takes a few second until the icon changes to green ) Click the Display button and the “Compare Results” is displayed in the navigation window.

© SAP AG E2E200 3-151

The parameter changes (different value, missing value, unchanged value and additional value ) are marked with different icons

© SAP AG E2E200 3-152

© SAP AG 2007

E2E Change Diagnostics Unit Overview Diagram

Lesson 2: E2E Change Analysis


Lesson 1: Configuration and File Reporting

© SAP AG E2E200 3-153

© SAP AG 2007

Configuration and File Reporting - Architecture

Java-based installationsJava-based installations

Diagnostics agentsDiagnostics agentsSolution Manager

Config store

Configuration and file reporting

Data collection once a day

Parameter values

The data is collected in Java based systems via Diagnostics Agents and in ABAP based systems via Solution Tool Plugin Extractors.

E2E Change Analysis uses the same tables as Configuration and File Reporting It enhances the functionality of the former Configuration and File Reporting by adding data of

ABAP based systems and by providing BI based reporting capabilities

© SAP AG E2E200 3-154

© SAP AG 2007

E2E Change Analysis - Architecture

Java-based installationsJava-based installations

Diagnostics agentsDiagnostics agentsSolution Manager

Config store

Configuration and file reporting


InfoCube

E2E change analysis

ABAP-based installationsABAP-based installations

Solution tool plug-insSolution tool plug-ins


Number of changes

Parameter values

The data is collected in Java based systems via Diagnostics Agents and in ABAP based systems via Solution Tool Plugin Extractors.

E2E Change Analysis uses the same tables as Configuration and File Reporting It enhances the functionality of the former Configuration and File Reporting by adding data of

ABAP based systems and by providing BI based reporting capabilities

© SAP AG E2E200 3-155

© SAP AG 2007

Change Groups and Change Types

ABAP Software VersionABAP Component ReleaseABAP PackagesSupport Package Level SAP NotesSAP Kernel

JAVA Software VersionJAVA Component ReleaseJAVA Support PackagesFixesPatches

TransportsWorkbenchCustomizingNon-ABAP

Operation SystemOS ParameterOS LevelOS Patch Level

DatabaseDB ParameterDB LevelDB Patch Level

ABAP System ConfigurationABAP Instance Parameter RFC Destinations

JAVA System ConfigurationJAVA Instance Parameter

BI, SCM, CRM, XI, …

This slide contains a list of change types, which are currently available or planned in E2E Change Analysis. The list will be developed further.

Change Types are the smallest unit which are counted and displayed in E2E Change Analysis. Change Types are bundled in Change Groups.

© SAP AG E2E200 3-156

© SAP AG 2007

Example: Data Source for ABAP Parameter

The table PAHI is the data source for the ABAP parameter

© SAP AG E2E200 3-157

© SAP AG 2007

Different Types of Data

Details not availableNumber of events is displayed in the overview Detail information is locatedin the managed systems

Details not availableNumber of events is displayed in the overview Detail information is locatedin the managed systems

Timestamp MethodNumber of events since last data collection run is transferred to E2E ChangeAnalysis

Timestamp MethodNumber of events since last data collection run is transferred to E2E ChangeAnalysis

Transports and PatchesPatches, SP, ReleaseBusiness ConfigurationContent (EP, XI, BI, SLD)Coding

Transports and PatchesPatches, SP, ReleaseBusiness ConfigurationContent (EP, XI, BI, SLD)Coding

Details availableNumber of changes is displayed in the overview Full configuration set can be displayed for each day

Details availableNumber of changes is displayed in the overview Full configuration set can be displayed for each day

Snapshot MethodDaily snapshot is transferredto E2E Change Analysis

Snapshot MethodDaily snapshot is transferredto E2E Change Analysis

Technical ConfigurationOS, DB, ABAP parameters

Technical ConfigurationOS, DB, ABAP parameters

Detail ViewerDetail ViewerData Collection Method

Data Collection MethodType of DataType of Data

In E2E Change Analysis, we differentiate between two types of data: Technical configuaration, like OS, DB and ABAP parameters. These parameters are not

recorded by the Change and Transport System. A full snapshot of each configuration set is extracted on each day.

Changes which are recorded in transport requests or Support Packages and Patches, are already documented in the managed systems. For these types of changes only the number of events since the last data collection run is transfered to E2E Change Analysis. Details are located in the managed systems.

© SAP AG E2E200 3-158

© SAP AG 2007

BI

ST

Data Extraction Process

E2E MainExtractorHOURLY

„Change Events“

E2E Change Analysis MainExtractorDAILY

„Configuration Changes“

E2E Change Analysis Other Infocubes

Configuration Store (SMD DB)

ConfigurationCollector(Wrapper)

SMD Scheduler

E2EExtraction Framework

E2EExtractionFramework

SMD

ABAP / JAVASystemABAP / JAVA

SystemABAP / JAVASystem

ABAP SystemABAP SystemABAP System

Java SystemJava SystemJava System

This diagram shows the data flow in E2E Change Diagnostics. The collection of the configuration parameters is shown on the left. Java based systems send

the parameters via the SMD agent to the config store. In ABAP based systems the configuration parameters are collected via ST-A/PI extractors. Data transfers for both Java and ABAP systems are triggered in the SMD Scheduler.

From the Configuration Database the configuration parameters are uploaded daily into the E2E Change Analysis infocube. This upload is controlled by the E2E Extraction Framework.

Recorded changes, like transport requests, SAP Notes or Support Packages are collected every hour by the E2E Extraction Framework. For these kinds of changes, no detailed information is stored in the Configuration Database. The number of events is uploaded directly into the infocube.

© SAP AG E2E200 3-159

© SAP AG 2007

Required Software Versions

May 200701J_CRM500ST-A/PI

July 2007SP6BI_Cont

August 2007SP13Solution Manager

August 2007SPS13NW04s

Planned AvailabilitySupport Package Release

© SAP AG E2E200 3-160

© SAP AG 2007

System Demonstration

System-Demo

© SAP AG E2E200 3-161

© SAP AG 2007

E2E Change Analysis - Overview

BSO B70

E2E Change Analysis is integrated into the Solution Manager Diagnostics. Navigate to Root Cause Analysis Configuration E2E Change Analysis. On the first screen, you see the number of changes for all systems of the solution in the

selected timeframe.

© SAP AG E2E200 3-162

© SAP AG 2007

E2E Change Analysis – Query Navigation

In the next step, select a system. When you open the Navigation Block, you can design individual queries. For example you

can display the number of changes per system, change type and calendar day.

© SAP AG E2E200 3-163

© SAP AG 2007

Detail viewer per change type and change day

For the details, jumpinto the configstores, displaying theparameter for theselected system and calendar day

The number of changes is context sensitive. Right-click on the figures in order to navigate into the context menu. Then select Goto Config Details to display the complete configuration set for the selected day.

© SAP AG E2E200 3-164

© SAP AG 2007

End to End Change Diagnostics: Unit Summary

You should now be able to:

Look up recent changes in the customer solutionsincluding:



Content (EP, XI, BI, SLD, …)

Coding

Compare Technical Configuration between landscapes

© SAP AG E2E200 3-166

Exercises

Unit: E2E Change Diagnostics Lesson: Configuration and File Reporting

At the conclusion of this exercise, you will be able to: • Use the configuration and file reporting in SAP Solution Manager

Diagnostics

This exercise has to be executed in the SAP Solution Manager Diagnostics of system TT4.

3-1 Logon to the Solution Manager Diagnostics in TT4 and perform the following

analyses. 3-1-1 What is the URL to logon to Solution Manager Diagnostics?

Answer: _______________________________________________ 3-1-2 Call the Configuration and File Reporting tool. What is the path?

Answer: _______________________________________________ 3-1-3 In the Landscape Selection choose the solution ESS Solution and the

system role Production System. In the Detailed Selection choose the host for the maininstance SAP XSS (Self Services). For which timestamps is configuration data available? Load the configuration data for the most recent timestamp.

3-1-4 In the View Configuration screen search for the configuration file “instance.properties”. What is the ConfigStore path and ConfigStore name? Answer: ______________________________________________ When was the file last changed? Answer: ______________________________________________

3-1-5 Click on the line to display the configuration parameters. Which of the parameters were changed? Answer: ______________________________________________ Check the parameter MaxHeapSize (server0). When was the parameter changed and what was the previous value?

© SAP AG E2E200 3-167

Answer: ______________________________________________

© SAP AG E2E200 3-168

3-1-6 Compare the complete configuration for the ESS Solution solution with an older version.

3-1-7 Perform a Deep Compare for the ConfigStores Path = DVEBMGS50/j2ee/

© SAP AG E2E200 3-169

Exercises

Unit: E2E Change Diagnostics Lesson: E2E Change Analysis

At the conclusion of this exercise, you will be able to: • Use the E2E Change Analysis tool to track all changes in a solution

This exercise has to be executed in the Solution Manager Diagnostics of the system TT4.

3-2 Perform the following analyses in the E2E Change Analysis tool.

3-2-1 Navigate to E2E Change Analysis. What is the path? Answer: _______________________________________________

3-2-2 Select the solution ESS Solution and the system role Production.Select the timeframe 01-Jan-2007 until 28-Feb-2007. What is the number of changes? Answer: _______________________________________________

3-2-3 What is the number of changes for each host of the solution? Host 1: _______________________________________________ Host 2: _______________________________________________ Host 3: _______________________________________________ …

3-2-4 Look at the system TT5. For which change groups and change types have changes been recorded? Answer: _________________________________________________ ________________________________________________________ ________________________________________________________ ________________________________________________________ ________________________________________________________ ________________________________________________________

© SAP AG E2E200 3-170

3-2-5 Go to the Navigation Block and take the changes per Calendar Day as additional columns into the table. On which day did most changes take place? Answer: _________________________________________________

3-2-6 Drill down into the configuration details for the latest Java parameter changes. Which parameters were changed on that day? Answer: _________________________________________________ ________________________________________________________ ________________________________________________________ ________________________________________________________ ________________________________________________________ ________________________________________________________

© SAP AG E2E200 3-171

Solutions

Unit: E2E Change Diagnostics Lesson: Configuration and File Reporting

3-1 Logon to the Solution Manager Diagnostics in TT4 and perform the following

analyses. 3-1-1 What is the URL to logon to Solution Manager Diagnostics?

http://<hostname>:50000/smd 3-1-2 Call the Configuration and File Reporting tool. What is the path?

Root Cause Analysis Configuration Configuration and File Reporting

3-1-3 In the Landscape Selection choose the solution ESS Solution and the system role Production System. In the Detailed Selection choose the host for the maininstance SAP XSS (Self Services). For which timestamps is configuration data available? Load the configuration data for the most recent timestamp. Make your selections and press the Start button. Check which timestamps are available in the listbox. Select the most recent timestamp and click on the Load button.

3-1-4 In the View Configuration screen search for the configuration file “instance.properties”. What is the ConfigStore path and ConfigStore name? In the View Configuration screen enter the filename “instance.properties” in the Search field and click on the Search button. In the next screen click on the Go to next button twice. The ConfigStore path is DVEBMGS50/j2ee/. The ConfigStore Name is cluster/instance.properties. When was the file last changed? Check the Date entry in the end of the line for the ConfigStore name.

3-1-5 Click on the line to display the configuration parameters. Which of the parameters were changed? All parameters with the icon were changed. Check the parameter MaxHeapSize (server0). When was the parameter

© SAP AG E2E200 3-172

changed and what was the previous value? Click on the button Attribute History to display the change date and the previous value.

© SAP AG E2E200 3-173

3-1-6 Compare the complete configuration for the ESS Solution solution with an older version. Go back to the screen Display landscape Production System of solution ESS Solution. Click on the Compare button. In Landscape 2 select an older timestamp and click on the Compare button. Now the screen Select Subtrees for Compare appears.

3-1-7 Perform a Deep Compare for the ConfigStores Path = DVEBMGS50/j2ee/ In the screen Select Subtrees for Compare select the ConfigStores Path = DVEBMGS50/j2ee/. Click on the button Deep Compare. In the next screen mark the same ConfigStore for landscape2, and click on Select. A new screen Compare Results appears. It shows all ConfigStores with changed parameters. Expand the list in order to see the changed parameters.

© SAP AG E2E200 3-174

Solutions

Unit: E2E Change Diagnostics Lesson: E2E Change Analysis

3-2 Perform the following analyses in the E2E Change Analysis tool.

3-2-1 Navigate to E2E Change Analysis. What is the path? Root Cause Analysis Configuration E2E Change Analysis

3-2-2 Select the solution ESS Solution and the system role Production.Select the timeframe 01-Jan-2007 until 28-Feb-2007. What is the number of changes? Select the timeframe Custom Selection and choose From 01.01.2007 To 28.02.2007. Click on the button SID. In the folder Overview a diagram appears that shows the number of changes in the selected timeframe.

3-2-3 What is the number of changes for each host of the solution? Click on the button Hosts. A diagram appears that shows the number of changes for each host in the selected timeframe.

3-2-4 Look at the system TT5. For which change groups and change types have changes been recorded? Click on the folder for system TT5. A table is displayed that contains a list of all Change Groups and Change Types for which changes were recorded in the selected timeframe. Click on the Change Groups to see the Change Types.

3-2-5 Go to the Navigation Block and take the changes per Calendar Day as additional columns into the table. On which day did most changes take place? Look at the following screenshot to see how to open the Navigation Block and take the changes per Calendar Day as additional columns into the table.

© SAP AG E2E200 3-175

Close the Navigation Block again and go back to the table. Now there should be a column for each Calendar Day. Compare the number of changes for each day.

3-2-6 Drill down into the configuration details for the latest Java parameter changes. Which parameters were changed on that day? Make a right mouse click on the number of changes for the latest Java parameter changes. In the context menu select Goto Config Details. A list of all parameters that were changed in that week is displayed.

© SAP AG E2E200 4-176

© SAP AG 2007


NetWeaver Development EnvironmentsEnhanced Change and Transport SystemTransport StrategiesChange Request Management




NetWeaver Development Environments

© SAP AG E2E200 4-177

© SAP AG 2007

Contents:

ABAP Development Workbench

NetWeaver Development Infrastructure

Enterprise Portal

Exchange Infrastructure

Software Deployment Manager


© SAP AG E2E200 4-178

© SAP AG 2007

NetWeaver Development Environments: Unit Objectives


Describe the different development environments, which are integrated in SAP NetWeaver


NetWeaver Development Infrastructure and itscomponents

Enterprise Portal Content Administrator

Exchange Infrastructure Integration Builder

Explain the functions of the Software DeploymentManager

© SAP AG E2E200 4-179

© SAP AG 2007

ABAP Change & Transport System


NetWeaverDevelopment Infrastructure

ABAP DevelopmentWorkbench Development

LandscapeQuality

LandscapeProductionLandscape

QualityComponent n

QualityComponent 1

ProductionComponent n

ProductionComponent 1

.

...

check in

Transport Transport

Deploy Deploy

EPA


Integration Builder

TPZ

Manage Heterogeneous Development Environments

Software Deployment

Manager

Software Deployment

Manager

…(open Interface for

non-ABAP objects)

The Enhanced Change and Transport System (CTS+) is an improvement on the established ABAP Change and Transport System.

It allows changes from heterogeneous development environments to be transported with the ABAP Change and Transport System.

Java Archives can be checked in to transport requests as transportable objects on the target system, after Import Methods are executed to deploy the Java archives via the Software Deployment Manager.

© SAP AG E2E200 4-180

© SAP AG 2007

NetWeaver Development Environments Unit Overview Diagram


Lesson 1: ABAP Development Workbench

Lesson 2: NetWeaver Development Infrastructure

Lesson 3: Enterprise Portal

Lesson 4: Exchange Infrastructure

Lesson 5: Software Deployment Manager

© SAP AG E2E200 4-181

© SAP AG 2007

Data Types in SAP Systems

Cross-client Customizing#

Customizing

# Appl.

data

Use

r

Customizing

# Appl.

data

Use

r

Modifications

CustomizingCustomizing

Customizing

Development

Customer Enhancements

SAP Repository

….

The SAP system contains different types of data. Some data can only be accessed from one client, such as business application data

(documents, material master), and most customizing settings Customizing is used to deifne a customers organizational structure. The client-specific data is closely related. Application data is checked against the customizing

settings in the client at input. If inconsistencies are found, the input is rejected. There are other settings, which 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, 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 E2E200 4-182

© SAP AG 2007

Integrated ABAP Development Workbench

Transaction SE80 is the integrated ABAP development workbench. All repository objects can be changed here.

© SAP AG E2E200 4-183

© SAP AG 2007

SAP Implementation Guide for Customizing

The Implementation Guide is a tool for creating customer-specific system settings in the SAP system.

The hierarchical structure of the Reference IMG: • reflects the Application Component structure in the SAP system • contains additional General Settings (valid for all applications) and Company Structure

(SAP organizational units, country- specific default settings) • lists all documentation relevant for the implementation of the SAP system • contains functions to create customizing settings

IMG structure elements: • Structure nodes • IMG activities

Call the Reference IMG with SPRO

© SAP AG E2E200 4-184

© SAP AG 2007

Cost cent er Edit Goto D etails E nviro nme nt Syste m Hel p

??

Global SettingsCountriesCurrenciesCalendars

Implementation Guide (IMG)

Customizing Organizer

CustomizingDEVK900124 Change Request

DEVK900125 TaskDEVK900126 Task

View Maintenance: DataV_TVAKV_TSPA

Transport Management System

Workbench Organizer

TransportableDEVK900131 Change Request

DEVK900133 TaskDEVK900134 Task

ABAP Program SourceZCDEMOZCACTION


ObjectBrowser

ABAPDictionary

ABAPEditor

FunctionLibrary

ScreenPainter

MenuPainter


Automatic Recording of Changes

SAP provides different implementation tools for Customizing and development. For Customizing: • The Implementation Guide (IMG) is the main Customizing tool. Once you decide which

R/3 modules you require, the IMG automatically generates a hierarchical list of steps (or Customizing transactions) for Customizing.

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

For development: • The ABAP Development Workbench provides access to development tools, which cover

the entire software development cycle. These tools may be used for both customer-specific development and SAP enhancements of R/3 applications.

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

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

© SAP AG E2E200 4-185

© SAP AG 2007

WorkbenchOrganizer - SE09

Customizing


Teamwork

Table change history (logging)

Connected to Client Administration and Transport Management System

Development


Teamwork

SSCR

Packages

Object locking

Version management

Connected to Transport Management System

CustomizingOrganizer - SE10

Customizing Organizer and Workbench Organizer

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

Customizing changes consist of table entries. Workbench change requests concern changes to R/3 Repository objects, such as ABAP

programs, screens, data dictionary objects and global documentation. Compared to Customizing, change management for development is more complex, requiring: • Registration of developers within SAP Software Change Registration (SSCR) • Development classes for R/3 Repository objects • Locking of R/3 Repository objects during development • Versioning of R/3 Repository objects

© SAP AG E2E200 4-187

© SAP AG 2007

check-out & change development objects

Logon to SAP development

system

activate changes

test application

releasetransport

NetWeaver Development Infrastructure: Learning from ABAP

JAVA

Defines the whole environment of own and foreign

componentsCorrect libraries are copied automatically

Implicit check forformal correctness

visibility for everyone

early integration

test application

copy & checkout source files, change development objects

logon to NWDI DevConfig

build centrally &activate changes

release fortransport

Developer testswithin the central

environment

ABAP

The SAP NetWeaver Development Infrastructure (NWDI) supports the Java software development throughout the entire software lifecycle: • Centralized administration of the development environment • Access to objects stored in the NWDI for developers integrated into the SAP NetWeaver

Developer Studio • Synchronization of development on sources and archive level • Synchronization of development teams across repository boundaries, allowing for a

customer modification concept • Development environment used by SAP's customers, partners and SAP's own development

As shown here, though there are many technical differences between ABAP and Java, many basic concepts of the development process have been integrated into Java development.

© SAP AG E2E200 4-188

© SAP AG 2007

Development environment (IDE)

Java

Run

time

Envi

ronm

ent f

or

the

SAP

Syst

ems

(DEV

,CO

NS,

...)

Dep

loym

ent

Local File

System

Component Model

ComponentBuild

Service(CBS)

Cha

nge

Man

agem

ent S

ervi

ce(C

MS)

Design Time Repository

(DTR)

LocalSAP

Web AS Java

Local Installation on Developer's PC

CentralInfrastructure

Local Build Tool

RuntimeSystems

Name ServiceSystem Landscape

Directory (SLD)

Building Blocks of NWDI

SAP NetWeaver Developer Studio (IDE, Integrated UI for all development tasks including those concerned with DTR, CBS, CMS and Name Service): SAP’s own development environment for developing multi-layer Java-based business applications. The new development environment is based on the open source product Eclipse. It fully supports SAP’s component model (SAP’s component model is a new way to structure software)

DTR: Central store for all types of source files. The store is presented logically as a hierarchical files and folders structure. The contents are physically stored in a database and can be accessed using the open protocols WebDAV and DeltaV.

CBS: Build Environment. The CBS stores all imported libraries (archives) to start development of new Software Components (SCs). It also builds and stores all newly created development components

CMS: Administration and quality management environment for (logical) development systems. It consists of the Landscape Configurator (responsible for the definition of development environments for specific SC releases (tracks with development configurations for development and consolidation)) and of the Transport Studio (that enables transport mechanisms for development components from Development Consolidation Assembly

Approval Name Service: Service to guarantee the uniqueness of names (technically, the Name Service is

an SLD)

© SAP AG E2E200 4-189

SLD: SAP J2EE application that contains all relevant information about software products and components (both ABAP and Java) that can be installed in a system landscape. It also contains a description of the current system landscape. The SLD also stores the development configurations.

Please note: SLD is not part of NWDI, but already part of standard SAP Web AS Java installation. SLD is required by the NWDI.

© SAP AG E2E200 4-190

© SAP AG 2007

SLD Used for Java Development

For Java development, SLD provides the following services:

Definition of software, products and software components to be developed with interdependencies

Naming Service:Reserve name spaces for unique names of development components

Storage of development configurations required for development

© SAP AG E2E200 4-191

© SAP AG 2007

Development Cycle Using NWDI – Overview

Track & Dev. Configs.

Delivery

SL Change Mgmt.

Development

Next Release

define

import

release

prepare

define

ADM

INIS

TRAT

ION

/ Q

MAD

MIN

ISTR

ATIO

ND

EVEL

OPM

ENT

Product. & SCs1. SLD: Define software to be developed

Define a product (including release number)Define one or more software components (SCs) that form the product and their dependencies

2. CMS: Set up the development landscapeDefine a track for the specific release of the SCDevelopment configurations are generated for each development state of an SC (DEV/CONS). Used SCs are imported.

3. Dev. Studio: Edit and build development objects

Use SAP’s Developer Studio with access to NWDI by importing the corresponding development configurationRelease objects for further processing by QM

4. CMS: Perform further administrative stepsTransport into next dev. steps, quality assurance, and assembly using the Change Management Service

5. CMS: Deliver SCs and patchesDeliver software component versions

6. CMS: For the next release define new versions

Development process: • Define a product in the SLD • Define the development environment (DTR, CBS, and RTS) in the CMS for each release • Developers SAP NW Developer Studios are configured specifically for each development

task by a simple file import from SLD/CMS - Developers use DTR and CBS which give them access to the sources and archives they

need (central storage guarantees consistency of all objects) - Objects are only activated after a successful central build, which guarantees that only

checked objects go into broader use. - Successfully tested objects go into further use in the software life cycle consolidation

steps and next release in a defined way. • In the CMS the next steps are carried out in a defined way: Consolidation, approval, and

assembly. • Manage the delivery (archives and/or sources) • For the next release, define the version number in the SLD and go through all steps again.

Create a new track, etc. ….

© SAP AG E2E200 4-192

© SAP AG 2007

Central Development

System

Consolidation System

Test system

Production System

3

Development Configuration

Entwickler

Development Configuration

21CB

Developer: Administrator:A

B

CheckIn 12

3

Import

Assembly & Import

Approval & Import

Buildspace

Software Component Archive (SCA)

Version i

Change Requests

Buildspace

WorkspacesWorkspacesWorkspacesWorkspaces

A

C

Activate

Release

Transports Within a Track – Overview

Netweaver Development Infrastructure

The figure above shows an overview of the transport process. Steps (A), (B) and (C) are performed by the developer whereas steps (1), (2) and (3) are performed by a transport manager or a quality manager.

After the Check-In (A) the developer activates (B) the sources from SAP NetWeaver Developer Studio. A central build process will be triggered. After a successful activation, the new binaries are deployed automatically into the central development system for central testing (if a runtime system for the development stage is defined within the track).

(C) After a successful test in the central development system, the developer releases the activity. The CMS creates a change request upon released activities. References to the released activities containing the relevant object versions are exported to the file system for transport. Finally, CMS adds the new change requests into the consolidation queue.

(1) The transport manager imports the appropriate change requests from consolidation queue. The import triggers the DTR import in inactive workspace, the CBS activation and – if a runtime system is available – an automatic deployment into the consolidation runtime system is started.

(2) After the consolidation stage, an assembly process will be started by the transport manager. During this step, all binaries (and sources, if necessary) in assured state are assembled into a component version. It is possible to test the assembled software component version again by deploying it to the test system (if configured in the track). After the component version has been successfully verified, it waits for approval for delivery.

© SAP AG E2E200 4-193

(3) The component version can then be approved by the responsible person. After approval, it can be imported into the productive runtime system of the track or it can be copied as SCA file from the file system and delivered to customers or deployed manually via SDM or JSPM.

© SAP AG E2E200 4-194

© SAP AG 2007

DevelopmentComponents

SoftwareComponents

ReleaseP1 P2

O1

D4

O3

D7

D8D6

D5

D11

D10D9

S1 S2

Products

SupportPackage

(Fix)

O2

Component Model in Delivery And Maintenance

Objects

The SAP component model for Java development is used in delivery and in the context of maintenance.

Software maintenance is organized into three tiers: Products are installed or undergo an upgrade to a new release. A release is a full delivery of

software components that provide new functions (and possibly user interfaces) or improvements. Installation and upgrade are not performed with CMS resources.

A Support Package (SP) is (unlike ABAP) a full delivery of one (or more) software component(s) and contains a number of fixes. The usual file format of an SP is the SCA format. Support Packages are implemented using the Java Support Package Manager Tool (JSPM). JSPM distinguishes between Systems that are under NWDI control and those that are not.

Fixes are full deliveries of a development component that allow quick error correction, before the complete SP is available. The usual file format is the SDA format.

• Hint: SAP usually does not yet deliver fixes. The smallest unit of delivery of SAP software is a Support Package.

Development Objects (DOs) • Stored as versioned files in the source repository (DTR) • Example: Web Dynpro view, table definition, Java source file

© SAP AG E2E200 4-195

© SAP AG 2006

Structuring Applications Using the Component Model

SC B(imported, read only)

SC A(imported,read only)

SC X(changeable)

Product X

DC

DC

DC

DC

DC

DC

DC

DC

DC

DC

consists of

uses

uses

DC

SAPNWDev.

Studio

CMS

SLD

Product • Business solution decided upon by management • Created in SLD • Made up of SCs

- New SC(s) (created in SLD) - Used SCs already available

New SCs • Provide a context for the creation of new DCs in the SC-compartment. • Only new SCs (not the used SCs) are changeable in the SAP NetWeaver Developer

Studio in the context of a development configuration. • Created in the SLD; composition of new and used SCs for the new product ( more

precisely: product version) in the CMS New DCs

• Provide a context for the creation of a new development objects • DCs have a type. For each type a build script is available • DCs provide

- project structures according to their type.

© SAP AG E2E200 4-196

- DC Meta Data with information needed for the build process etc. (see slide with DC structure).

• DCs define the visibility of their development objects. • DCs define the use of other DCs. • DCs structuring the complete SC by use of parent DCs and inner DCs

Development objects • All file types used in Java/J2EE • SAP-specific files in Web Dynpro • Meta Data files used in automated processes of the NWDI • Component model-specific files such as DC and SC definition files • Two file types:

- Created: Stored as versioned objects in the DTR - Generated: Not stored in the DTR

Files are automatically chosen by the SAP NetWeaver Developer Studio (settings can be adjusted in the studio)

© SAP AG E2E200 4-197

© SAP AG 2006

Source Code Management in the DTR – Basics

Distributed, concurrent development

Distributed versioning that spans repositories

Conflict detection

Support for conflict resolution

Files and FoldersDTR knows only files and folders

No knowledge about objects of programming model (classes, tables, screens etc)

Check in/check out modelFiles are checked out from DTR and modified “offline”

Files are checked in again when change is complete

The DTR provides central storage, versioning and management of java sources and other resources with an automated conflict detection and resolution. The Developer Studio enables comprehensive DTR support for all available project types (Web Dynpro, EJB,...).

Distributed, concurrent development – the DTR addresses the needs of large scale development:

• Some projects are so big that the development team is spread over different locations. The groups will work in parallel. The same requirements you have if you want to allow your customers to do modifications to your applications, which means modifications to the Java source code.

• The versioning mechanism of the DTR that spans repositories means that you can safely propagate changes from one DTR repository to another

• The conflict detection allows to detect, if two versions of one development object have been created in parallel and prevents inconsistent states of versions

• Conflicts that are reported by the DTR can of course be solved there: A conflict is always a uncertainty, which of two versions of a certain file shall be active in the DTR (see workspaces for details); the content of the conflicting versions can be displayed and the user can decide how to solve the conflict (see conflicts for details).

Files and Folders:

© SAP AG E2E200 4-198

• Though the DTR stores all objects in a database the content of this database is presented to the DTR client in a files and folders fashion. This meets the concepts of the Eclipse-based SAP’s IDE the SAP NetWeaver Developer Studio.

• The storage of files is independent of the programming language so in principle all types of files can be stored and versioned, even if they are not part of the Java programming model.

© SAP AG E2E200 4-199

Check in/check out model: • To change a file in the DTR you must check it out: To change them you will use a copy

in your local file system (see changing resources for details). • Changed objects will be checked back in to the DTR server – all changes will be part of

an activity then.

© SAP AG E2E200 4-200

© SAP AG 2007

Design Time Repository – Modification Adjustment

WSSAP WScust

b1

Install

Apply SP

Accept / reject or merge integrated version

conflict

a1

a2

a1

a2

b2

Scenario:The same file was changed in two workspaces concurrently Propagation of changes from one workspace to another integration conflict

Distributed versioning and conflict resolution:

Changes are recognized as versions of same fileImported versions are correctly placed in version graphNo risk of overwriting changes in target repository

Example: There is a WS at SAP where an application is developed. The sources are delivered to a customer together with the archives. The customer uses his or her installation of the NWDI to modify the source code.

A new source object is created in SAPs workspace and stored in the DTR as version a1. This version is delivered to and installed at the customer’s site.

The customer modifies a1 in a customer workspace WScust and creates version b1. In the meantime, a version a2 is created in WSSAP and delivered as SP1. The customer now integrates the content of SP1 into his WS: Version a2 is detected as

conflicting with b1. The customer now has three conflict resolution options – his or her modifications are not

overwritten automatically. The whole version tree of a development object is always transported along with the actual

version of the object. We call this a global version history. He or she can choose to accept the new version from SAP. All subsequent transports will not

cause conflicts. He or she can also reject SAP’s new version a2 or merge his version b1 with a2 by creating a

new customer version b2

© SAP AG E2E200 4-201

Version conflicts not only can occur during check-in of an activity – they can also happen during integration of an activity into another workspace (WS): A version of the same file that is neither a predecessor nor a successor of the new version has to be integrated into a workspace. Therefore, you have to decide about the active version in the workspace.

DTR – Distributed Versioning NWDI distinguishes the following conflicts: Check-in conflicts during normal course of development in every workspace. Integration conflicts when sources are used and changed over workspace boundaries (e.g. for

different releases of the same product).

© SAP AG E2E200 4-202

© SAP AG 2007

CBS

Component Build Service (CBS)

Buildspace

DC 3 Archives

Temporary Folder

DTR

Build

DC 2

DC 4 Archives

DC 1 Archives

DC 2 Archives

DC 1

DC 3

DC 4

inactive workspaceDC 2

active workspace

DC 2

a b c

a b c d

DC 2

a

b

c

d

d

activate

DC 5 Archives

DC n Archives

Changes in DC 2 are activated. DC 2 uses DCs 1,3, and 4.If any DC uses DC 2, it will be rebuilt when DC 2 is activated.

d

Act.dedit

VR d

DC 2 is to be developed. DC 2 uses (is dependent on) DC 1, DC 3 and DC 4. A developer checks in his activity, which contains the modified source object d and activates

this change. The CBS pulls the actual version of all source objects belonging to DC 2 from the inactive

workspace. They are compiled based on the actual binary versions of the used components from the archive pool of the CBS.

Once the build succeeds, the DC 2 is activated, which means that its actual binary version is stored in the archive pool and is visible for all dependent components. The corresponding source versions are copied into the active workspace at the same time.

If there are any components depending on DC 2, they will be rebuilt according to internal build requests created by CBS.

© SAP AG E2E200 4-203

© SAP AG 2007

NWDI

Design TimeRepository

ComponentBuild Service

CMS

Tran

spor

t Stu

dio

Land

scap

e C

onfig

urat

or

EnterprisePortal

CustomDevelopment

PureSourceControl

Dev

. Stu

dio

ModificationMgmnt

NWDI – Scenario Overview

ProcessIntegrat.

Process Integration: • Tracks & Transports – no development in Developer Studio, no use of DTR.

Portal: • Portal application DCs (restriction: Missing DCs; workaround: External Library DCs). • Portal content is created in Portal Content Studio and transported via DC Portal Content in

Developer Studio (restriction: Not supported; workaround described in How-To-Guide “Transporting SAP Enterprise Portal 6.0 Content” (in SAP Service MP alias nw-howtoguides).

Custom Development: • Development of arbitrary software using the component model of Java/J2EE + SAP

specific types (J2EE, Java, Dictionary objects, Web Dynpro, etc.). Modification Management: • Solutions (e.g. ESS) shipped by SAP (or any other vendor), that are developed in the

NWDI can be modified safely. SPs can be imported later, without losing the modifications: Merging of older and newer file versions has to be done manually, but is supported in the Developer Studio.

• This is based on the automatic conflict detection mechanisms of the DTR. Pure Source Control

© SAP AG E2E200 4-204

• It is possible to store any type of file in the DTR – this also includes (non-DC) project files created in the Developer Studio.

© SAP AG E2E200 4-206

© SAP AG 2007

Visible Portal Objects

iView

Page

DetailedNavigation

Top-levelNavigation

iView

Folders can contain documents, other items, and other folders. In an iView in the portal, you can navigate through portal structures and access the items they contain.

iViews are logical portal content building blocks, representing a visual application. Pages hold iViews and other pages containing iViews, organized in a layout. Roles are the largest semantic content object. A role is a folder hierarchy comprising other

content objects (worksets, pages, iViews). Worksets represent generic, re-usable structures or modules that can be added to roles. Portal Content Directory is the central persistence for all portal objects. This includes, for

example, storage of the metadata for the content objects (roles, worksets, etc.) and the relationship between the objects.

© SAP AG E2E200 4-207

© SAP AG 2007

Role

workset 3

iView 1iView 2

workset 1 workset 2

workset 2.1 workset 2.2

iView 1iView 2iView 3

iView 1iView 2

iView 1iView 2

Portal Content Directory (PCD) Objects

The Enterprise Portal provides a role-based user interface

Page 1 Page 2

Role:One or more page(s) may contain relevant content for each role.

Worksets:Within each page, worksets group related tasks and content. Worksets are not visible elements.

•Page:Each visible page contains visible iViews which provide access to applications, reports, services, and information. A page provides top-level and detailed navigation panels.

•iViews:A visible iView provides a specific piece of information within a page.

Navigation

The business package is structured as follows: • For each role, one or more business packages are provided with the required content. • Each business package contains the content needed to complete the various tasks a person

with that role typically has to complete. These collections of task-oriented content are called “worksets.”

• Each workset consists of those iViews required to complete the tasks in that workset. iViews are the smallest content units. They contain the actual resources needed to complete the tasks that make up each workset.

The following PCD Objects may need to be maintained by means of SAP or other vendors‘ shipments, for example, a Business Package shipped in iViewStudio: • Folders (and their content) • iViews • Pages • Worksets • Roles

The Enterprise Portal Import / Export iView is used to transport the PCD objects. Local changes to the current object version will be overwritten by the import of the associated

EPA file.

© SAP AG E2E200 4-208

The file type for exports / imports of PCD Objects is EPA (Enterprise Portal Archive) Any PCD Object (including „folders“ and their content) can be exported from one Enterprise

Portal System and imported into another one. The EPA file may also contain *.PAR files, if the PCD objects being exported have been

created based on their components. If PCD Objects are delivered as part of Business Packages, updates can be imported from

iViewStudio.

© SAP AG E2E200 4-209

© SAP AG 2007

Packaging Model – Packaging Portal Transport Archives

Scenario A: Import and Export EPA-Files including PAR-Files via Portal Import/Export ToolYou want to import and export portal content objects and includedepending par-files (like EP6.0 SP2).

Scenario B: Import and Export EPA-Files without PAR-Files via Portal Import Export ToolYou want import and export portal content objects only

You pack the portal content objects into one EPA archive. You export objects to an EPA archive with the portal export function. You import the objects with the portal import function.

Scenario C: Import and Export SCAs and SDAs via SDMYou want to store portal content objects in an archive together with PAR files. It should be possible to deploy this archive to the portal with the SDM.

You export the portal content objects to an EPA archive in portal administration. PAR archives are created in the development environment. To combine the two archive formats into one archive, they must be converted to other formats.

It is important to use either the PAR-in-EPA or the PAR-in-EAR mechanism - if you use the latter approach, especially, you have to avoid that PARs are included into EPAs during export. This can cause inconsistent transports, because the PAR may depend on other parts of the EAR file (e.g. logging configuration) that is not included in the EPA file. • When you perform an export in portal administration, individual portal content objects are

packed in an archive in EPA format. In the past, EP 6.0 SP2, PAR files were also contained in EPA archives. However, in EP 6.0 on 6.40, there are two options on how to configure the content of export packages:

• Option 1: Include par-files in an export package (as in EP 6.0 SP2) • Option 2: Exclude par-files form an EPA archive.

- There are no longer PAR archives in an EPA archive. When you pack transport archives, portal applications (executable Java code packed into PAR archives) are strictly separated from portal content objects (roles, worksets or pages, packed in EPA archives) during the export.

- Portal applications are handled as part of the Java Enterprise applications and are packed into PAR archives in the development environment. PAR archives can be contained in archives with EAR format (Enterprise Archive) as modules. Different J2EE applications can be combined in EAR archives, for example PAR applications and

© SAP AG E2E200 4-210

Web Dynpro applications. You can pack portal content objects into an archive together with PAR files and other J2EE applications.

- This type of archive can be deployed to the portal with the SAP Software Deployment Manager. To pack EPA and PAR archives into an archive, they must first be converted to other formats (SDA and SCA). Command line tools are provided for this purpose.

© SAP AG E2E200 4-211

© SAP AG 2007

PCD Objects – The Export Function

Using the property Pcd.TransportApplication.ProtectedNamespacesin the file global/config/pcd/pcdStartup.template.propertiesnamespaces can be generally excluded from exportation.

This tool is used to export any type of PCD Object except for “Themes”.

In addition, while exporting a transport package, you can decide to export only name spaces of your choice.

A Transport Package can be created using the Export iView. Almost all types of PCD objects can be added to the Transport Package to be then exported.

The only PCD Object type for which a dedicated export function must be used is the Theme.

© SAP AG E2E200 4-212

© SAP AG 2007

PCD Objects – The Import Tool

The Enterprise Portal Import iView is used to upload the new PCD objects (except by „Themes“).

If the EPA file contains any PAR files, they will be uploaded correctly onto the portal as well. No additional PAR upload is necessary.

Using the property Pcd.TransportApplication.ProtectedNamespaces in the file global/config/pcd/pcdStartup.template.properties namespaces can be excluded from importation.

© SAP AG E2E200 4-213

© SAP AG 2007

SAP Enterprise Portal File Types

SAP NetWeaver Packaging Model

EPT PAR WDA

EAREAP

DevelopmentComponent



Represents a

Represents a

Software entity with own life cycle

Single deployable archive

Runtime-internal sub-archives

…

SCA

SDA

SCA – Software Component ArchiveSDA – Software Deployment Archive

EPA – Enterprise Portal ArchiveEPT – Enterprise Portal Transport

PAR – Portal ArchiveEAR – Enterprise Application Archive

WDA – Web Dynpro Application

SDA: Software Deployment Archive (The smallest unit that patches can be created and delivered for) • The delivery format for SAP applications in program languages other than ABAP.

SCA: Software Component Archive • The physical representation of a version of a software component, which contains a

specific number of SDAs. EAR: • A special case in the J2EE context, mostly contains J2EE specific XML files and satisfies

the requirements of J2EE. • SDM will not rename EAR during the deployment.

© SAP AG E2E200 4-215

© SAP AG 2007

Execution of Collaborative Business Processes

Shared Collaboration Knowledge

Integration Builder

IntegrationDirectory

(ID)

IntegrationRepository

(IR)

IntegrationServer

(IS)

System Landscape Directory (SLD)

Central Monitoring

SAPSystems

3rd PartySystems

3rd PartyMiddlewareComponent

Marketplace/BusinessPartner

PI Component Overview

SAP PI consists of the following components: Design Time / Configuration Time • The Integration Builder: A client-server framework for accessing and editing two stores of

Shared Collaboration Knowledge: - The Integration Repository: For the design and development of Interface, Process, and

Mapping objects that are used to implement Integration Scenarios. - The Integration Directory: For configuring scenarios from the Integration Repository in

the concrete customer landscape. - By separating design time activities from configuration time activities, SAP can ship

content for the Integration Repository, which each customer can implement for their specific landscape in the Integration Directory. As far as possible, the goal is to reduce the problem of developing interfaces to the simpler task of configuring interfaces.

Runtime • The Integration Server: The central processing engine of the PI. All messages, whether

SAP or non-SAP, A2A or B2B, regardless of backend technology or vendor, are processed in a consistent way.

• Central Monitoring: To give a comprehensive and focused view of all components and processes at runtime.

© SAP AG E2E200 4-216

SLD • The System Landscape Directory: a central repository of information about your system

landscape and software components. This data is required during design- and runtime.

© SAP AG E2E200 4-217

© SAP AG 2007

SAP Web AS≥ 6.20

Integration Builder – Design Time

Integration Repository


Software ComponentSoftware Component Version

J2EE/ABAP

ProxiesMessage Interfaces

Message Types

Integration Builder

Interface Editor

Data Types

Business Processes

Mappings

Business Scenarios

Context Objects

Scenario Editor

Process Editor

Mapping Editor

Condition Editor

BPEL

XSLTJava

XPath

WSDL

XSD

The development of a collaborative process begins with its design. In the Integration Repository, we can define the messages and interface for an integration scenario separately for the outbound and inbound components. Mapping programs are then created to transform messages as they are processed. These objects are stored in the Integration Repository and are associated with software component versions that belong to a product to be shipped.

Message Interfaces describe which data can be transferred by a message. Data Types are predefined data structures; Message Types are for example IDOC’s. Mappings describe the relationship between inbound and outbound interfaces.

Messages can be transferred to ABAP systems via Proxies. If the proxy has to be adjusted this requires changes in the ABAP stack which are transported by ABAP transport requests.

© SAP AG E2E200 4-218

© SAP AG 2007

DB

UI Client

Server

IntegrationDirectory

IntegrationRepository

Integration Builder Server Framework

Integration Builder – Generic Functions

Query Service & Cross ReferencesImport/Export & CMS interfaceInternationalizationChange list ManagementVersioningLockingAuthorization & Authentication

Integration Builder Client Framework

Layout Building BlocksPersonalizationNavigation

The Integration Builder Server Framework provides software logistics features like Locking, Versioning and Change List Management.

It provides an Import/Export interface as well as an interface to CMS of the NWDI. Changes are saved in user-specific change lists. To make these changes visible for all users of

a repository, the developer must activate the entire change list.

© SAP AG E2E200 4-219

© SAP AG 2007

Integration Builder – Configuration Time

Integration Directory

Collaboration ProfilesParties & Services

Channels

Integration Builder

Business Processes

Routing Rules

Scenarios

Collaboration Agreements

Receiver Determination Rules

Interface Determination Rules(including Mapping Assignment)

Security

Configuration Editors

Configuration Wizards

The Integration Directory is used to configure the sender-receiver relationships which will be used at runtime for specific systems. The configuration data is structured, organized, and saved in the Integration Directory in the form of configuration objects.

The following objects are managed in the Integration Directory: • Routing Rules describe how to find the receiver system and interface if a message of a

certain type comes from a certain sender system and interface. • Collaboration Agreements describe details on the data exchange between a receiver and

sender interface, e.g. if handshake is used. • Collaboration Profiles describe in which way data is exchanged between a sender and

receiver interface, e.g. files can be copied into a certain directory in the receiver system or they can be sent to an ftp-server

The Collaboration Agreements and Communication Profiles can be transported, but since configuration data may differ in the source and target environments, special elements like passwords and adapter meta data cannot be exported. Therefore, you have to recreate the information in the target environment manually.

© SAP AG E2E200 4-220

© SAP AG 2007

Transport of PI Objects via Export/Import

Integration Repository Objects:Integration ScenarioActionIntegration ProcessMessage InterfaceMessage TypeFault Message TypeData TypeData Type EnhancementExternal DefinitionContext ObjectInterface MappingMessage MappingMapping TemplateImported ArchiveAdapter MetadataCommunication Channel TemplateFunction ModuleABAP Dictionary TypeIDocIDoc Message TypeIDoc TypeIDoc SegmentIDoc Extension

All objects of the Integration Repository (Business Scenarios, Interfaces and Mappings) can be transported.

The Integration Builder provides an Import/Export interface as well as an interface to CMS of the NWDI.

© SAP AG E2E200 4-221

© SAP AG 2007

Import of PI Objects

Copy the .tpz file to the target PI server in the following folder:

…\usr\sap\<SID>\SYS\global\xi\repository_server\import

Launch the wizard for importing design objects and finish the steps.

The imported file will be moved to the following folder:

…\usr\sap\<SID>\SYS\global\xi\repository_server\import\importedFiles

After exporting, we can locate the file in the following folder on the source PI server:…\usr\sap\<SID>\SYS\global\xi\r

epository_server\export

© SAP AG E2E200 4-222

© SAP AG 2007

Transport of PI objects via NWDI (CMS)

SAP NetWeaverCM

S

PI-Track YDirectory

SC X (Definition)

PI-Track XRepository

SLD

Names (reserv.)

DTRCBS TransportS

tudio

LandscapeC

onfigurator

Change Management Service

SAP NetWeaverUsage Type PIRepository• SC version

• Data Types• Message T.• ...

• SC version

Directory• Business Scenario• Party• Services• …



• SC version




• SC version


With NWDI used PI systems are set

in tracks

With NWDI PI, transports can be managed centrally in these tracks

Consolidate Productive

In the NWDI PI-tracks are defined for PI Repository and Directory content. In these PI-tracks the URLs of the used PI-Systems for Dev/ Cons/ Prod and SC versions to be

developed are set. All transports can be managed centrally using the CMS Transport Studio. • Note, that the synchronization of transports for 2 tracks is a manual task.

However, with the central approach using the CMS transport this has become significantly easier.

© SAP AG E2E200 4-223

© SAP AG 2007

PI uses SLD:

As a server for business system names

Management of software component versions

Transport targets for directory content transports

End-to-end monitoring of Runtime Workbench

The SLD content is the prerequisite for the PI transportation. An error message will occur, if the imported Integration Repository or Integration Directory objects cannot find related entities from the SLD

There are two main areas of content in the SLD: the software catalog and the system catalog • The software catalog describes the installed products and their constituent components.

The software catalog is delivered with content about all SAP products. Customers and partners can extend this catalog with information about software from other vendors.

• The system catalog describes the systems in the data center from two perspectives: a logical view (business systems) and a physical view (technical systems). In other words, the system catalog describes the concrete implementation of the customer landscape.

Information from the software catalog is used in the IR to organize development efforts. Information from the system catalog is used in the ID to drive the specific configuration of Integration Scenarios.

© SAP AG E2E200 4-224

© SAP AG 2007

Activity Sequence when transporting PI objects

Maintain the groups and transport targets in the System Landscape DirectoryExport the Integration RepositoryExport the Integration DirectoryExport and import the System Landscape Directory (only in the case of multiple SLDs)Copy the exports from the source host directory to the target hostImport the Integration RepositoryImport the Integration DirectoryRework data in the Integration Directory (end points and logon data)Activate distribution in Directory

Before development begins, a software component version must be available in the System Landscape Directory and assigned to a product version. This is normally carried out by a development manager.

When development begins, the development manager or project manager imports the software component version from the System Landscape Directory into the Integration Repository and defines the namespaces for development. Furthermore, for each imported software component version he or she can define a system from which RFCs or IDocs can be imported.

With the namespaces now available, development can begin with the design of the business processes in the repository. Changes are saved in user-specific change lists. To make these changes visible for all users of a repository, the developer must activate the entire change list.

To ship the objects in the repository, you must export them in a file. You may want to export the objects so as to import them into a test system, for example.

When developing a new version of the product, you normally increase the version number of the software component and the product from step one. By using release transfer, you can transfer objects from other software component versions into the new software component version.

© SAP AG E2E200 4-226

© SAP AG 2007

Software Deployment Manager – Features

Software Deployment Manager (SDM) is used to deploy Java patches, hotfixes or business packages.

Provides the ability to track changes or code updates to softwarecomponents on the J2EE Engine.If needed the SDM controls the restart of the satellite systemduring the deployment process.Deployment in filesystems and databases is managed.Undeployment of a software component with dependencies.Calculation of dependencies between archives.Version control of archives. No overwriting of newer versions.

© SAP AG E2E200 4-227

© SAP AG 2007

SDM Repository

The SDM Repository contains the registered Software Component Archives (SCAs) and Software Deployment Archives (SDAs).

Select a component to see its detail information (version, vendor, dependences).

© SAP AG E2E200 4-228

© SAP AG 2007

Deployment of new Archives

The SDM Interface appears.

1) Click on the Deployment tab

You use the Deployment tab to deploy new software packages with the Software Deployment Manager (SDM). The SDM takes you through the individual steps, from selecting the Software Component Archive (SCA) and the Software Deployment Archive (SDA), to actually deploying the software in the target directory.

© SAP AG E2E200 4-229

© SAP AG 2007

Undeployment

You can use the undeployment function to remove installed applications from the J2EE Engine.

Only components which have no dependency to other components can be undeployed.

© SAP AG E2E200 4-230

© SAP AG 2007

Dependency Graph

In the SDM repository, right-click the component and choose “Show Dependency Graph”.

© SAP AG E2E200 4-231

© SAP AG 2007

Log Viewer

You use the Log Viewer tab to display the log for the SDM work steps. You can display the work steps of the server and the graphical user interface (GUI)

© SAP AG E2E200 4-232

© SAP AG 2007

NetWeaver Development Environments: Unit Summary


Describe the different development environmentsintegrated in SAP NetWeaver


NetWeaver Development Infrastructure and itscomponents


Exchange Infrastructure Integration Builder

Explain the functions of the Software DeploymentManager

© SAP AG E2E200 4-234

Exercises

Unit: Netweaver Development Environments

In this exercise, you can check if you know the different Netweaver Development Environments and their basic concepts

This exercise consists of questions and answers.

4-1 Which of the following components is not part of NWDI but required by NWDI?

Please choose the correct answer.

Change Management Service (CMS)

System Landscape Direcory (SLD)

Design Time Repository (DTR)

Component Build Service (CBS)

© SAP AG E2E200 4-235

4-2 Which of the following statements are correct with regard to Netweaver Development Environments? More than one answer is correct. Decide whether each answer is true or false.

True False

The SAP NetWeaver Development Infrastructure (NWDI) supports the Java software development throughout the whole software lifecycle

The ABAP Development Workbench provides access to development tools, which does not cover the entire software development cycle

The name services of the NWDI is part of the Change Management Service (CMS)

The ABAP Development Workbench provides version management for repository objects

4-3 PI/XI uses the System Landscape Directory (SLD) as …?

More than one answer is correct. Decide whether each answer is true or false.

True False

As a server for business system names

Adapter framework for 3rd party products

Management of software component versions

Version and change list management

© SAP AG E2E200 4-236

Solutions

Unit: Netweaver Development Environments

4-1 Which following component is not part of NWDI but required by NWDI?


O Change Management Service (CMS)

X System Landscape Direcory (SLD)

O Design Time Repository (DTR)

O Component Build Service (CBS)

4-2 Which of the following statements are correct with regard to Netweaver

Development Environments? More than one answer is correct. Decide whether each answer is true or false.

True False

X O The SAP NetWeaver Development Infrastructure (NWDI) supports the Java software development throughout the whole software lifecycle

O X The ABAP Development Workbench provides access to development tools, which does not cover the entire software development cycle

O X The name services of the NWDI is part of the Change Management Service (CMS)

X O The ABAP Development Workbench provides version management for repository objects

© SAP AG E2E200 4-238

4-3 PI/XI uses the System Landscape Directory (SLD) as …? More than one answer is correct. Decide whether each answer is true or false.

True False

X O As a server for business system names

O X Adapter framework for 3rd party products

X O Management of software component versions

O X Version and change list management

© SAP AG E2E200 5-239

© SAP AG 2007






Enhanced Change and Transport System

© SAP AG E2E200 5-240

© SAP AG 2007

Contents:

Transport of non-ABAP Objects

Configuration

Process Flow

Tracking of Changes

Benefits of Change Request Management


© SAP AG E2E200 5-241

© SAP AG 2007

Enhanced Change and Transport System: Unit Objectives


Explain the concept of transporting Non-ABAPobjects with the Enhanced Change and Transport System

Track changes in JAVA systems

Know how Change Request Management supportschanges of non-ABAP objects

© SAP AG E2E200 5-242

© SAP AG 2007

Enhanced Change and Transport System Unit Overview Diagram


Lesson 1: Transport of Non-ABAP Objects

Lesson 2: Configuration

Lesson 3: Process Flow

Lesson 4: Tracking of Changes

Lesson 5: Benefits of Change Request Management

© SAP AG E2E200 5-243

© SAP AG 2007

Motivation to Extend the Change and Transport System

Change and Transport System (CTS) and NetWeaverDevelopment Infrastructure provide powerful functions to control transports in ABAP and JAVA.

What was missing?Synchronized import into double stack systemsA solution for the transport of Portal contentA central administration interface for all types of transports and systemsTracking and management of Non-ABAP objects with Change Request Management

The open issues are addressed with the Enhanced Change and Transport System

© SAP AG E2E200 5-244

© SAP AG 2007

Enhanced Change and Transport System (CTS+)

Connect Java Systems to standard CTSNon-ABAP applications inherit all properties of the ABAP Change and Transport System in terms of documentation, tracking and troubleshooting featuresManages transport of ABAP and non-ABAP-objects centrallyAllows combined transports for mixed objects (ABAP, JAVA, …)Allows synchronized changes to business processes whichrun in ABAP and JAVA100% Compatible with SAP Solution ManagerNo need to upgrade of Java landscapes

© SAP AG E2E200 5-245

© SAP AG 2007

Change and Transport System

Developer Studio

andNWDI


Integration Builder

ABAP Workbench

SE80 DevelopmentLandscape

QualityLandscape

ProductionLandscape

QualityComponent n

QualityComponent 1

ProductionComponent n

ProductionComponent 1

.

.

.

.

.

.

check in

Transport Transport

Deploy Deploy

SCA

Enterprise Portal

Content Administrator

EPA

Manage Heterogeneous Development Environments

…(open Interface for

non-ABAP objects)

The Enhanced Change and Transport System (CTS+) improves the well proven ABAP Change and Transport System.

It allows changes from heterogeneous development environments to be transported with the well proven ABAP Change and Transport System.

Java Archives can be checked in to transport requests as transportable objects on the target system, after Import Methods are executed to deploy the Java archives via the Software Deployment Manager.

© SAP AG E2E200 5-246

© SAP AG 2007

Supported Solutions and Deployment Options

Transport of:Enterprise Portal objects (EPA, PAR)Objects from NWDI (SCAs,…)Objects from XIInterface for Non-SAP applications

Deployment Options: SDMXIFS

Transport of: • ABAP transport objects • Enterprise Portal objects (EPA, PAR) • Objects from NWDI (SCAs,…) • Objects from XI • Interface for Non-SAP applications

Will be developed further (e.g. integration with Maintenance Optimizer) Other applications can be supported if they provide deployment procedures. Currently there are deployment services for: • SDM, XI, FS (filesystem)

© SAP AG E2E200 5-248

© SAP AG 2007

Transporting Non-ABAP Changes

Legend

logical transport route of non-ABAP objects

physical transport route of non-ABAP objects

check-in/check-out of non-ABAP objects

transport route of ABAP objects


Non-ABAP

Virtual QAS Virtual PRD

Java DEV Java PRDJava QAS

SAP NetWeaver Application Server CTS+

Non-ABAPNon-ABAP

New System Type:

Virtual Non-ABAP System

Transport parameter

contain deploy options

A Java transport landscape is represented by an ABAP transport landscape. The transport controller must be a physical ABAP system (at least NW04s, SPS12), in which

the transport routes are configured. Transport Requests are created on the transport controller. The Java Development Environment checks in Java Archives into the transport request. Then, the transport request is imported into the virtual non-ABAP systems. In the After-

Import Method, the Java Archives are deployed via Software Deployment Manager

© SAP AG E2E200 5-249

© SAP AG 2007

Java Stack: Example EP (or XI Java Stack)

EPDev. System

EPQA System

EPProd. System

CTS+TransportController

ABAP

Java

Java Java Java

CTS+

DeployService

DevEnv DevEnv DevEnv

NW04s = SPS12

Upload of Archive

NW04s < SPS12 NW04s < SPS12 NW04s < SPS12

Virtual QAS Virtual PRDImport Import

1

2

3

4Deploy in EP QA System via SDM

TP calls Deploy Service

The Transport Organizer (SE09) of a CTS+ Transport Controller is used to manage the transport requests for the Java stack of the Java system

Own transport route and separate transport requests for the Java stack are required Solution Manager and ChaRM can be used to synchronize ABAP- and Java stacks’ transport

requests. CTS+ Server controls the imports into the Java stack of the Java system

© SAP AG E2E200 5-250

© SAP AG 2007

Double Stack Installation: Example XI

XISource System

ABAP stack

Java stack

XITarget System

ABAP stack

Java stack

Transport Route

Transport Request

ABAP Objects

Java Objects

XIDev. System

XIQA System

XIProd. System

ABAP

Java

ABAP

Java

ABAP

Java

CTS+

DeployService

CTS+

DeployService

CTS+

DeployServiceIB IB IB

NW04s = SPS12 NW04s = SPS12 NW04s = SPS12

Transport Transport

Changes to ABAP objects are recorded automatically by CTS Changes to XI repository and XI directory objects have to be checked in into a CTS transport

request manually One transport request may contain the changed ABAP objects and the changed XI repository

and dictionary objects. Import of the XI repository and directory objects into the Java stack of the XI system is

controlled by the transport control program tp Technically, the import into the Java stack is one additional import step which starts the XI

import client via the CFS deploy web service Imports can be scheduled and monitored by TMS

© SAP AG E2E200 5-251

© SAP AG 2007

STMS Configuration in the Transport Controller

In this example, the transport controller is B7T. An XI landscape and a Portal landscape are connected to the transport controller.

© SAP AG E2E200 5-252

© SAP AG 2007

Transport Parameters for the Virtual Non-ABAPSystems

EP System XI System

EPQ is a virtual, non-ABAP system which represents an Enterprise Portal QA system. The transport parameters for deployment are: • DEPLOY_DATA_SHARE \\trans70.wdf.sap.corp\trans70\OTO\data • DEPLOY_OUTBOX /tmp/oto/out • DEPLOY_URL http://wdfd80077398a:53018 • DEPLOY_WEB_SERVICE CTSDEPLOY

XIQ is a virtual non-ABAP system which represents an XI QA system. The transport

parameters for deployment are: • DEPLOY_DATA_SHARE \\trans70.wdf.sap.corp\trans70\OTO\data • DEPLOY_WEB_SERVICE CTSDEPLOY • DEPLOY_XI_URL http://ldciu7s:52000/rep

© SAP AG E2E200 5-254

© SAP AG 2007

Web Service for Deployment

Web Service for Deployment

Web Interface to Transport Organizer

Assign archive to transport request


Create Transport Request

Portal - DEV

Create content

Enhanced Change and Transport System -Process

Portal - QAS

Portal - PRD

Release Transport Request

Virtual QAS

Virtual PRD

Export Java Archive

Call Web Service (Close

Coupling)

Import

Import

Deploy

Deploy

Deploy

Deploy

The complete workflow of the Enhanced Change and Transport System is shown in this figure.

In the Close Coupling scenario the CTS Adapter Web Service is called from the Java Development Environment and the Java Archive is automatically transferred.

In the Loose Coupling scenario the CTS Adapter Web Service cannot be called from the Java Development Environment. In this scenario the Java Archive must be exported to the File System. Then the CTS Adapter Web Service is called and the Java Archive is searched and uploaded from the file system.

When a transport with a non-ABAP file is imported into the virtual QAS system then the non-ABAP file is transfered to a Web Service for Deployment. This Webservice then deploys the file to the right application.

In case of EP or NWDI the deployment tool is the Software Deployment Manager.

© SAP AG E2E200 5-255

© SAP AG 2007

Create Transport Request

The first step is to create a transport request in the Transport Controller

© SAP AG E2E200 5-256

© SAP AG 2007

Export Java Archive

At the same time, the content of the Java application is developed and exported into the file system.

In the „Close Coupling Scenario“ there is a button „Start Export“ which leads you directly to the CTS Adapter Web Service

© SAP AG E2E200 5-257

© SAP AG 2007

Web Interface to the Transport Organizer

Assign Objects to Transport Requests and Release Request

In the CTS Adapter Web Service you can attach Non-ABAP objects to transport requests and release the transport request

© SAP AG E2E200 5-258

© SAP AG 2007

Import Request in Virtual Non-ABAP System

Then, go to the import queue of the virtual non-ABAP system which represents the QA system.

Import the transport request. In the After-Import Method Execution, the Java Archive is deployed by the Software

Deployment Manager

© SAP AG E2E200 5-259

© SAP AG 2007

ABAP Stack

Runtime

Java Stack

SystemRuntime

Build Env.

Workbench

Repository

ABAP Stack

Runtime

Java Stack

SystemRuntime

Build Env.

Workbench

Repository

ABAP Stack

Runtime

Java Stack

SystemRuntime

Build Env.

Workbench

Repository

ABAP Transport Landscape vs. CMS Track (NWDI)

PROD SystemQA System

TMS: 3-System-Landscape

DEV SystemConsolidation Delivery

Change Requests

Change Requests

CMS: Track„QA System“

CONS SystemPROD SystemTEST SystemDEV System

DevelopmentConfiguration

CONS System

Runtime System

DevelopmentConfigurationChange

RequestsSCASCA

assemblyRuntime System

Runtime SystemRuntime System

ABAP SystemABAP SystemABAP System

SAP NetWeaver - ProductionSAP NetWeaver – Quality AssuranceSAP NetWeaver - Development

The figure above compares the typical ABAP 3-System-Landscape from the Transport Management System (TMS) with the Java CMS Track Concept that allows 4 development stages.

In ABAP development there usually is one central development system (DEV) in that all the development takes place. When the development team has finished the development, the corresponding change request is released and can then be imported into the Quality Assurance System (QA). The changes are tested in the QA system. After a successful test, they can be approved and imported into the production system (PROD).

In Java development (scenario “Developing Components with the NWDI”) however there are four development stages within a track: development (DEV), consolidation (CONS), test (TEST) and production (PROD). Up to four runtime systems can be assigned to this track.

If you now consider the development SAP systems that have both the AS ABAP and the AS Java runtime environment, you may map the ABAP 3 system landscape to the Java 4 system landscape by combining the Java consolidation system and the Java test system to a “QA System” and map this system to the ABAP QA System. This can be done by either omit the test system completely in the CMS Track or by omitting the CONS runtime system and use the TEST runtime system instead.

The question whether the QA runtime system should be assigned to CONS or TEST cannot generally be answered. There are advantages and disadvantages for both variants:

© SAP AG E2E200 5-260

• In you use the CONS runtime system then the deployment to the runtime system is started immediately after the build in CONS. This means that the integration of sources, build and deployment is performed as one “import“ task in CMS.

• If you use the TEST runtime system however (as indicated in the figure above), the assembled SCAs get deployed. In this case you are absolute sure that you test exactly this version you will later deliver to production.

© SAP AG E2E200 5-261

© SAP AG 2007

ABAP Stack

Runtime

Java Stack

SystemRuntime

Build Env.

Workbench

Repository

ABAP Stack

Runtime

Java Stack

SAP NetWeaver – Quality Assurance

SystemRuntime

Build Env.

Workbench

Repository

ABAP Stack

Runtime

Java StackSAP NetWeaver - Development

SystemRuntime

Build Env.

Workbench

Repository

CMS: Track

PROD System

TMS: 3-System-Landscape

DEV System

Synchronization of ABAP and Java Transports

SCA

Change Requests

SCA

assembly

QA System PROD SystemChange Requests

SCA

deployment istriggered by tp

import

check-in to ABAP change request

CONS SystemCONS System

Runtime System


DEV System


Runtime System

ABAP System

Java RuntimeABAP System

ABAP System

Java Runtime

SAP NetWeaver - Production

The figure above compares the typical ABAP 3-System-Landscape from the Transport Management System (TMS) with the Java CMS Track Concept that allows 4 development stages.

In ABAP development there usually is one central development system (DEV) in that all the development takes place. When the development team has finished the development, the corresponding change request is released and can then be imported into the Quality Assurance System (QA). The changes are tested in the QA system. After a successful test, they can be approved and imported into the production system (PROD).

In Java development (scenario “Developing Components with the NWDI”) however there are four development stages within a track: development (DEV), consolidation (CONS), test (TEST) and production (PROD). Up to four runtime systems can be assigned to this track.

If you now consider the development SAP systems that have both the AS ABAP and the AS Java runtime environment, you may map the ABAP 3 system landscape to the Java 4 system landscape by combining the Java consolidation system and the Java test system to a “QA System” and map this system to the ABAP QA System. This can be done by either omit the test system completely in the CMS Track or by omitting the CONS runtime system and use the TEST runtime system instead.

The question whether the QA runtime system should be assigned to CONS or TEST cannot generally be answered. There are advantages and disadvantages for both variants:

© SAP AG E2E200 5-262

• In you use the CONS runtime system then the deployment to the runtime system is started immediately after the build in CONS. This means that the integration of sources, build and deployment is performed as one “import“ task in CMS.

• If you use the TEST runtime system however (as indicated in the figure above), the assembled SCAs get deployed. In this case you are absolute sure that you test exactly this version you will later deliver to production.

© SAP AG E2E200 5-264

© SAP AG 2007

Tracking of Changes

Use the Import History to find information on transports in Non-ABAP systems:

Object ListsTransport Logfiles

The Import History can be accessed from any system in theTransport Domain

© SAP AG E2E200 5-265

© SAP AG 2007

Import History of Non-ABAP System

By using the ABAP Change and Transport System, Java applications inherit all properties of the ABAP CTS.

The Import History can be reached from transaction STMS: Overview Imports <SID> Goto Import History

Here, you can find the list of all transports which were imported into a system and the import timestamp.

From the import history, you can navigate through the object list and the transport logfiles

© SAP AG E2E200 5-266

© SAP AG 2007

Navigate through the Object List

From the Import History you can navigate through the object list. By doubleclicking on the GUID of the Non-ABAP object you reach the Non-ABAP object

details. Here you can find the name of the archive. Further information will be developed, e.g. content of the Java Archive.

© SAP AG E2E200 5-267

© SAP AG 2007

Navigate through the Transport Logfiles

From the Import History you can navigate through the transport logfiles. In the detailed logfile for the Deployment step, you can see if the deployment was successful. You can also see further information, like host and port of the SDM.

© SAP AG E2E200 5-269

© SAP AG 2007

Different Levels of Control



Enhanced Change and Transport System (CTS+)SAP System ABAP Stack

ABAP

BetterControl

BetterControl



Java .net …..

Change Request Management in SAP Solution Manager is 100% compliant with the Enhanced Change and Transport System.

On the lowest level, transports are executed with proprietary Java tools. These Java tools can be controlled by the Enhanced ABAP Change and Transport System

(CTS+). This allows better control of transports. Furthermore, the documentation, tracking and troubleshooting possibilities are improved.

On the next level of control, transports in the ABAP Stack can be managed by Change Request Management in SAP Solution Manager. This increases the control of the full change process, including the incident, approval process and change realization process.

© SAP AG E2E200 5-270

© SAP AG 2007

TransportLandscapeCRM

TransportLandscapeEP

TransportLandscapeBW

TransportLandscapeERP

TransportLandscapePI

Development Landscape QALandscape

ProductionLandscape

DevelopmentEnvironment

SE80DS & DI

Portal ContentAdministrator

System

mySAP ERP

mySAP CRM

System

mySAP ERP

mySAP CRM

EnterprisePortal

System

mySAP ERP

mySAP CRM

EnterprisePortal

BW

EnterprisePortal

BW BW

ProcessIntegration

(XI)

ProcessIntegration

(XI)

ProcessIntegration

(XI)

DS & DI

SE80

SE80Integration

Builder

SE80DS & DI



Change Request Management in a Mixed ABAP/JAVA Landscape

Change Request Management can handle dependent transports in different systems. In this example, the Solution Manager Project comprises several SAP systems. The systems

have dependent transports. All transports for the whole solution are bundled under the umbrella of the Solution Manager project. When the project goes live all transport requests that belong to the same Solution Manager project are imported at the same time. So all dependencies are considered automatically.

© SAP AG E2E200 5-271

© SAP AG 2007

Enhanced Change and Transport System: Unit Summary


Explain the concept of transporting Non-ABAPobjects with the Enhanced Change and Transport System

Track changes in JAVA systems

Know how Change Request Management supportschanges of Non-ABAP objects

© SAP AG E2E200 5-272

Exercises

Unit: Enhanced Change and Transport System

At the conclusion of this exercise, you will be able to: • Transport Java Archives via CTS+ • Control the success of the imports

The ABAP stack of the SAP Solution Manager TT4 is configured as CTS+ Transport Controller. Enterprise Portal content will be imported into the Java stack of system TT5.

5-1 Create a transport request on TT4 for an Enterprise Portal Archive (EPA) and import it into the Enterprise Portal on TT5.

5-1-1 Logon to the Enterprise Portal on system TT5. What is the URL to logon? Answer: ____________________________________________________ 5-1-2 In the tab Content Administration open the folder Portal Content. Goto

Browse the Portal Catalog and check if there is an entry for “com.sap.OTO_Training” with a user specific iview under Portal Content.

Answer: ____________________________________________________ 5-1-3 Logon to the system TT4. Create a transport request of type Workbench.

Insert a Non ABAP object into the object list of the transport request. Select an Enterprise Portal Archive for your username out of the directory G:\SHARE\E2ECC\OTO. Release the transport request.

5-1-4 Import your transport request into the virtual Non ABAP system JAQ in transaction STMS.

5-1-5 Check in the transport log files if the import was successful. 5-1-6 Check in the object list for the name of the Java archive. 5-1-7 Check the transport route configuration. 5-1-8 Check the TP parameter settings for the Non ABAP system JAQ. What are

the values for: DEPLOY_URL :

_______________________________________________ DEPLOY_WEB_SERVICE:

______________________________________

© SAP AG E2E200 5-273

5-1-9 Logon to the Enterprise Portal on system TT5. In the tab Content Administration open the folder Portal Content. Goto Browse the Portal Catalog and check if there is an entry for “com.sap.OTO_Training” with a user specific iview under Portal Content.

© SAP AG E2E200 5-274

Solutions


5-1 Create a transport request on TT4 for an Enterprise Portal Archive (EPA) and

import it into the Enterprise Portal on TT5. 5-1-1 Logon to the Enterprise Portal on system TT5. What is the URL to logon? Answer: The URL is http://<hostname>:55000/irj. The username and

password will be provided by the trainer. 5-1-2 In the tab Content Administration open the folder Portal Content. Goto

Browse the Portal Catalog and check if there is an entry for “com.sap.OTO_Training” with a user specific iview under Portal Content.

Answer: At the beginning of the exercise this Portal Content object should not be available.

5-1-3 Logon to the system TT4. Create a transport request of type Workbench. Insert a Non ABAP object into the object list of the transport request. Select an Enterprise Portal Archive for your username out of the directory G:\SHARE\E2ECC\OTO. Release the transport request.

Logon to TT4 and start transaction SE09. Create a new workbench request with the Create button. Insert a short description for your transport request and save. Position the curser on the modifiable request and press the button Include Objects in the toolbar ( ). Choose now Non ABAP Objects and insert the directory G:\SHARE\E2ECC\OTO.. Assign the epa file “com.sap.OTO_Training_UserXX_20070314_103400.epa” relying to your userid. Set the attributes EP Enterprise Portal and SDM. To finish

this activity release the transport request with the release button. ( )

© SAP AG E2E200 5-275

5-1-4 Import your transport request into the virtual Non ABAP system JAQ in

transaction STMS. In TT4, start the transaction STMS and go to Transport Overview. Double

click on the JAQ system and press the refresh button. Select your transport and import it with the Import Request button ( ).

5-1-5 Check in the transport log files if the import was successful.

Select your transport and click on the Logs button ( ). There are logfiles for the import and the deployment. Click on the logfile for the deployment and read the content of the logfile.

5-1-6 Check in the object list for the name of the Java archive.

Select your transport and click on the Object List button ( ). Expand the list of Non ABAP objects and doubleclick on the GUID. You see the object that you have attached to the transport request.

5-1-7 Check the transport route configuration. In transaction STMS goto Overview Transport Routes. 5-1-8 Check the TP parameter settings for the Non ABAP system JAQ. What are

the values for DEPLOY_URL and DEPLOY_WEB_SERVICE? In transaction STMS goto Overview Systems. Double click on JAQ and

select the tab Transport Tool. DEPLOY_URL = http://<hostname>:<port> DEPLOY_WEB_SERVICE = CTSDEPLOY 5-1-9 Logon to the Enterprise Portal on system TT5. In the tab Content

Administration open the folder Portal Content. Goto Browse the Portal Catalog and check if there is an entry for “com.sap.OTO_Training” with a user specific iview under Portal Content.

Answer: At the end of the exercise this Portal Content object should be available.

© SAP AG E2E200 6-277







Transport Strategies

© SAP AG E2E200 6-278


Content:

System Landscapes

Client Strategies

Release Management

Transport Dependencies

Critical Objects

Transport Strategies: Unit Content

© SAP AG E2E200 6-279


Unit Objectives


Understand the limitations of the 3 system landscape and the benefits of advanced transport topologies

Understand the different client roles

Describe pros and cons of parallel projects, synchronized releases and maintenance cycles

Know how to manage transport dependencies

Be aware of critical objects

© SAP AG E2E200 6-280


Transport Strategies: Unit Overview Diagram


Lesson 1: System Landscapes

Lesson 3: Client Strategies

Lesson 4: Release Management

Lesson 5: Transport Dependencies

Lesson 6: Critical Objects

Lesson 2: Best Practises for Running the NWDI

© SAP AG E2E200 6-281





Three System Landscape

Standard Transport Process

Risk: Import Single Strategy

Risk: Inconsistencies in the Transport Landscape

Advanced Topologies

© SAP AG E2E200 6-282


Three-system-landscape

DEV

CR

CR

1

QASCR

PRDCR

CR

2 3

Buffers

A three-system-landscape consists of a development system DEV, a quality assurance system QAS and a productive system PRD.

The development system DEV is needed to implement changes. In the quality assurance system QAS performs functional tests and integration tests with

production-like data. This system is also needed to test the import of the change requests. Without a quality

assurance system, the import of transports cannot be tested before it is executed in production.

© SAP AG E2E200 6-283


Step 1: The Transport Request is Released

DEV

CR

CR

1

QASCR

PRDCR

CR

Buffers

Systems

Step 1:

The transport request CR is released. Development objects which are locked, are released and the change request CR is written to the import queue of the quality assurance system.

The import queue has two functions. The first one is that it contains all change requests that have been released, and the second is to remember the sequence, in which the change requests have been released.

© SAP AG E2E200 6-284


Step 2: The Transport Request is Imported into QAS

CR

QASCR

CR

2

DEVCR

PRDCR

Buffers

Systems

Step 2:

The complete import queue for the quality assurance system QAS is imported. System QAS is used for first tests with production-like data and, therefore, the import of the

complete transport buffer should be done in short time intervals, for example, every 15 minutes.

This can be scheduled automatically. The change requests that are imported are also written to the import queue of the productive

system PRD. This guarantees that the change requests and their import sequence to the quality assurance system QAS are remembered.

© SAP AG E2E200 6-285


Step 3: The Transports are Imported into Production

PRDCR

CR

3

DEVCR

QASCR

CR

Buffers

Systems

Step 3:

The import buffer of the productive system is imported into production.

© SAP AG E2E200 6-286









Advanced Topologies

© SAP AG E2E200 6-287



Problems:Transport requests are imported in an individual sequenceRisk of forgotten transportsRisk of version downgrades by overtakers

SolutionsImport project or mass import strategy

There are several risks in a three-system-landscape: The following slides explain these risks in more detail.

© SAP AG E2E200 6-288


Risk: Forgotten Transports

PROG ZREPORT …CALL ZMODULE…

•FUNC ZMODULE

DEVDEVK900001

QAS PRDDEVK900001

1

DEVK900002 DEVK900002


2

Test of ZREPORT in QAS is o.k.

3

DEVK900002

Generation of ZREPORT will lead to error


4

Transport request DEVK900002 contains a report ZREPORT which calls the function module ZMODULE in request DEVK900001.

In QAS DEVK900001 and DEVK900002 are tested together. The test is ok. But then only DEVK900002 is transported into PRD. It fails because DEVK900001 was

forgotten.

© SAP AG E2E200 6-289


Risk: Downgrading Object Versions


•FUNC ZMODULE

DEVDEVK900001

QAS PRDDEVK900001

1

DEVK900002 DEVK900002


2

Test of ZREPORT in QAS is o.k.

3

DEVK900002


4

Old version of ZREPORT is active in PRD


•FUNC ZMODULE

5

DEVK900001

Transport request DEVK900002 contains a report ZREPORT which calls the function module ZMODULE in request DEVK900001.

In QAS DEVK900001 and DEVK900002 are tested together. The test is ok. However, only DEVK900002 is transported into PRD. It fails because DEVK900001 was

forgotten. Now DEVK900001 is also imported into PRD. But the test in PRD fails again because now

the old version of ZREPORT (version of DEVK900001) has overwritten the newer version (version of DEVK900002).

© SAP AG E2E200 6-290


Project buffer Project buffer

Consistency of Project Cycles with Import Project

DEV QAS PRD

Legend:

Project transport requests

If there are more than five developers, the only way to avoid these kind of transport errors is to use the „import all“ or „import project“ method.

© SAP AG E2E200 6-291









Advanced Topologies

© SAP AG E2E200 6-292


Systems

Inconsistencies in the Transport Landscape

DEV QAS PRD

Open Developments

Transports not yet in PRD

Inconsistencies between DEV, QAS and PRDOpen developments in DEV which have not yet been exportedTransports in QAS which have not yet been imported to PRD

Transport requests which are in transition, but have not been imported into production result in inconsistent systems. Therefore, programs can still work in QAS but might fail in PRD.

© SAP AG E2E200 6-293


Risk: Inconsistencies in the transport landscape

Reasons:Sequence violationsTransports which were not transported completelyTransports stay in the import buffer of QAS or PROD too longWrong initial system set upSeveral parallel projects with different project timelinesProjects and maintenance in parallel

Solutions:Appropriate transport strategyPre-Production System

There are several risks in a three-system-landscape: The following slides explain these risks in more detail.

© SAP AG E2E200 6-294


Systems

Detecting Version Inconsistencies during Bug-fixing

DEV PRDQAS

1) Error in production Object 1 must be maintained

Object 1 is different

Obj1

2) Object 1 is already changed in DEV and cannot be maintained

Objects which have been changed in a project that is currently in transition cannot be maintained anymore during bug-fixing.

© SAP AG E2E200 6-295


Systems

Version Compare for Fixes between DEV and PRD

DEV PRDQAS

Object 1 is different

Obj1-V2 Obj1-

V1

1) Comparing active DEV object version with active PRD object version

2) Evtl. intermediate switch DEV object version for fix

You can compare the object versions in DEV and PRD before a maintenance task. If the versions are different, then you have to temporarily switch back an old object version from the version history in the development system. This object version is corrected and transported to production. In the next step the correction is done again with the latest object version.

This procedure is not possible for BW objects, because they do not have a version history.

© SAP AG E2E200 6-296


Systems

Detecting Cross Reference Errors during Bug-fixing

DEV QAS PRD

1) Error in production Object 1 must be maintained

Obj1 Obj2-V2

2) Object 1 uses Object 2. Object 2 was changed by the project

Error in PRD

Obj1 Obj2-V1

4) Error in PRD because Object 2 is still in the old version

Obj1 Obj2-V2

3) Test in QAS is ok

Test in QAS is ok

In this example Object 1 was not changed by the project. But Obj1 uses Obj2, and Obj2 was changed. At the beginning Obj1 does still work.

Now Obj1 has to be corrected. The new version of Obj1 does still work with the new version of Obj2. However, the new version of Obj1 does not work with the old version of Obj2. This is only detected in PRD.

For example Obj1 could be a program that reads data from a table (Obj2). At the beginning, the program reads data from the first 3 columns of the table. Then, an additional column is added to the table. If the program now also reads data from the new column, this only works with the new version of the table. It will fail in PRD.

© SAP AG E2E200 6-297


DEV QAS PRDPRE

Cross-Reference Inconsistencies and Pre-Production

Obj1-V2

Obj2-V2

Obj1-V2

Obj2-V2 Obj1-

V2Obj2-

V1

Obj1-V1

Obj2-V1

The Pre-Production System (PRE) has the current software/configuration state of production

The next urgent correction or project cycle can be isolated in PRE

Cross Reference Errors can be detected before they go into Production

The solution to cross-reference inconsistencies is a Pre-Production system. If the Pre-Production system has the current software / configuration state of production, the error can already be detected and fixed in Pre-Production.

© SAP AG E2E200 6-298





Problems in a Three System Landscape

Advanced Topologies

Pre-Development or Sandbox System

Pre-Production System

Phased System Landscape

Hotfix System

Template Rollout Landscape

© SAP AG E2E200 6-299


Pre-Development or Sandbox System

DEV QAS PRD

SBX Sandbox System

Early Prototyping without impacting the Development State

Takeover from Sandbox to Development must be done manually

Advantages: • Work in PRE without disturbing the maintenance landscape • No obsolete developments in DEV

Disadvantages: • Manual redo of development work in DEV is recommended • Transports might be possible if there are no conflicts with changes in DEV

Typical Scenario: • Playground system for developers • Long running projects can be kept out of the current transport landscape in the prototyping

phase Recommendation: • The system must be refreshed from time to time by the development system so that it stays

on a current software/configuration level

© SAP AG E2E200 6-300


DEV QAS PRDPRE

Pre-Production System

The Pre-Production System (PRE) has the current software/configuration state of production plus the next coming change

The next urgent correction and project cycle can be isolated in PRE


Advantages: • Protection against syntax errors due to cross-reference related inconsistencies, when

moving ‘isolated changes’ to production • Separation between ongoing Unit Tests in QAS and Integration Tests in PRE. Often there

are frequent imports of all development tasks into QAS. This does not allow a proper integration test by the business department at the same time.

The Pre-Production System is strongly recommended in most cases. Only in the following cases, might a 3 system landscape be sufficient: • The number of changes is very low • Only maintenance is done, no new functionality is developed • This landscape allows to conduct parallel projects with different Go-Lives, e.g. rollout

projects.

© SAP AG E2E200 6-301


Pre-Production System in a Three System Landscape

DEV PRDPRE

Development and Unit Test takes place in the same system

The Pre-Production System (PRE) has the current software/configuration state of production plus the next coming change

The next urgent correction and project cycle can be isolated in PRE


If an additional system is too expensive, then we recommend simulating the unit test system in an additional client within the development system. This workaround provides you with a “logical” 4 system landscape.

In this landscape client dependant changes cannot be unit tested in a separate system. See the lesson “Client Strategies” for more details.

© SAP AG E2E200 6-302

© SAP AG 2006

Phased System Landscape (Project and Maintenance)

Maintenance Landscape

QAS

Project Landscape

DEV TST

Cut-Over

Ret

rofit

PRDCON

Leading DevelopmentSystem (no copy)

Advantages: • Imcompatible new implementations or upgrades can be managed in parallel to maintenance • New software states ( Support Packages Stacks ) can be implemented without changing the

state of CON Disadvantages: • More Effort -> Retrofit from CON to DEV • Cut-Over requires code freeze in maintenance cycle • Cut-Over must be incorporated into maintenance cycle • Maintenance is difficult after the cut-over from TST to CON. An additional maintenance

system might be needed • More Systems

Recommendations: • Activate Version Management during Import/Deploy for CON (Transport parameter

VERS_AT_IMP = ALWAYS) • Activate customizing logging (transport parameter RECCLIENT = ALL, Profile parameter

rec/client=ALL) • Manage namespace conflicts for BI query development • All performed Retrofits must be incorporated into Cut-Over Release • Projects must be incorporated into the next maintenance cycle

© SAP AG E2E200 6-303

Typical Scenarios: • The phased system landscape is most appropriate if only one major project, with a fixed Go-

Live date, is developed in the project landscape. The maintenance is then performed in the maintenance landscape.

© SAP AG E2E200 6-304

© SAP AG 2006

Phased System Landscape II


QAS

Project Landscape

DEV TST

1) Cut-Over

Ret

rofit

PRD

REG

2) Sync CON and QAS

CON

Leading DevelopmentSystem (no copy)

Description of the procedure: • First, the new release is imported into the regression test system. • Then, the new release is imported into production. • Finally, the new release is imported into CON and QAS. • Advantages (compared with Dual Landscape): • Maintenance is still possible in CON and QAS during the regression test. • It is possible to run several parallel projects in the project landscape. Only the project which

goes live next is allowed to enter into REG. Disadvantages (compared with Dual Landscape): • A codefreeze in the maintenance landscape is recommended during the regression test phase • More Systems needed

Typical scenarios: • Synchronized releases (e.g. quarterly) or parallel projects in the project landscape • Minor maintenance cycles in the maintenances landscape (e.g. daily or weekly cycles) • Rollout scenarios (e.g. rollouts to different countries)

© SAP AG E2E200 6-305


Template Roll-out Landscape

Regional/Functional/Local/ 1

CON1 QAS1 PRD1

Central Development

DEV TST CON2 QAS2 PRD2

CON3 QAS3 PRD3

– Corporate Template Development

– Corporate Template Test

– Cut-Over Development

– Test & Verification

– Production

Cut

-ove

rC

ut-o

ver



Procedure • Corporate templates are developed in the corporate development landscape • The cut-over landscapes adjust the template to their local requirements and add additional

functionality • On the long term all cut-over landscapes are on a different software configurations • Advantages • Corporate functions can be developed and tested once centrally (harmonized business

processes) • Regional / functional / local requirements can flexibly be added in the cut-over landscapes • Corporate functions can be fast maintained in cut-over landscape and retrofitted into the

next corporate release • Go-Life dates of corporate releases can be managed individually by each cut-over

landscape Disadvantages • The rollout of a new template into the cut-over landscapes is challenging and risky as the

cut-over landscapes and the corporate development landscapes are inconsistent. Therefore this landscape is not recommended.

• Administrative effort to decide what is global what is local

© SAP AG E2E200 6-306

• More complex system landscapes • Central maintenance takes a longer way to production • Recommondations • …

© SAP AG E2E200 6-307

• … • Regional / functional / local developments should be encapsulated in separate namespaces • Regional / functional / local customizing should be restricted to certain number ranges • Global namespaces should be locked in the cut-over landscapes (SE06) • Global Customizing should be locked in the cut-over landscapes by using BC Sets • Typical Scenarios • Certain processes have to be implemented centrally. Other processes have to be

implemented only in single regions/locations/functional areas • Business processes need to be harmonized but there are still different requirements in

different regions/locations/functional areas

© SAP AG E2E200 6-309


Track for Development of a New Release

CONS

RuntimeSystem

DEV

RuntimeSystem

Test

PROD

DEV TEST

Approval

RuntimeSystem

Prod

Track: DEV

Since the Change Management Service (CMS) of the NWDI enables you to attach up to four runtime systems to a track - one for each state of the software - the following use of runtime systems has proven itself as most effective. • Runtime system 'Development': Immediate testing of the newest changes. The runtime

system in the development state is especially effective when it is combined with regular automated tests, for example an automated test that runs every night. In this way a lot of errors can be detected very early in the process. The overall quality of the software improves.

• Variant:If you think that local tests by the developers are sufficient for the overall quality of your software, it is possible to omit the runtime system from the development system. The first integration test system will then be the runtime system of the "Test" system.

• Runtime system 'Test': Testing of consolidated software state.This system offers a test environment for the software that mirrors the production environment.

• Runtime system 'Production': Deployment in the production system

© SAP AG E2E200 6-310


Tracks for the Maintenance of a Release

TEST

Track: DEV

CONSDEV

Development

PROD

Track: COR

TEST

Maintenance

DEVCONS

The maintenance of a release is supported by NWDI using a second track. A transport connection delivers changes from the development track to the maintenance track. A repair connection transports corrections made in the maintenance state back into the development track, thus avoiding double maintenance where possible.

After a software version has been deployed in the production system, you are confronted with the problem that you need to patch the production state, while at the same time you are developing new functionality in the development location. To avoid double maintenance of these corrections, they are transported automatically to the development location if a repair connection is configured between the tracks. The following procedure outlines the back transport process for the developers: • Release your transport. It shows up in the import queue of the previous track immediately. • Import the transport. • Check in the conflict view after the import into DEV, resolve the conflicts and activate the

change. • Release your transport if you had to resolve a conflict. This resolves the conflict in the

follow-on workspaces automatically. For a detailed description of the maintenance scenario, see the SAP NetWeaver library:

(http://help.sap.com -> ... -> Application Maintenance with the NWDI)

© SAP AG E2E200 6-312


Data Types in SAP Systems

Cross-client Customizing#

Customizing

# Appl.

data

Use

r

Customizing

# Appl.

data

Use

r

Modifications

CustomizingCustomizing

Customizing

Development

Customer Enhancements

SAP Repository

… .

The SAP system contains different types of data. Some data can only be accessed from one client, such as business application data

(documents, material master), and most customizing settings. Customizing is used to define a customer‘s organizational structure. The client-specific data is closely related. Application data is checked against the customizing

settings in the client, at input. If inconsistencies are found, the input is rejected. There are other settings, which are set once and are active for all clients. These client-

independent Customizing settings include, for example, printer settings. The repository is also client-independent. It contains all ABAP dictionary objects (tables, data

elements, 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 E2E200 6-313


Different Client Roles in 4 System Landscape

Authorizations

Gold ClientFor refreshes

DEV Test (SCC1)

Client Dependant Changes

Client independent Changes

Quality Assurance

ProductionPre-Production

Client independant changes: • All workbench and client-independant cutsomizing changes are carried out in this

client. There is a delivery route from this client into the QAS system. • There is no need to import client independant changes into the other clients in the

development system. • Client dependant changes: • All client dependant customizing changes are carried in this client. It can be

separated from the development client for two reasons: - Faciliate the authorization concept: Separate developers and customizers in

different clients - Ability to setup client dependant transport routes from the customizing client

into the other clients of the development system. This is not needed for the development client.

DEV Test Client: • This client contains test data, and is regularly refreshed by the gold client.

Customizers are supposed to test their work in this client by SCC1 copies after they have performed a customizing change in the customizing client.

• Authorizations:

© SAP AG E2E200 6-314

• This client is used for authorizations and user profiles. • Gold client: • This client contains test data and is used to refresh the DEV Test Client using

regular client copies.

© SAP AG E2E200 6-315


Different Client Roles in a Three System Landscape

Quality Assurance

Production

Gold ClientFor refreshes

Authorizations

Unit Test

DEV Test (SCC1)

Client Dependant Changes

Client Independent Changes

If a fourth system is too expensive, then we recommend that you simulate the unit test system in an additional client in the development system. This workaround provides you with a “logical” 4 system landscape.

The client specific transport routes go from the customizing client into the Unit Test client. Once the requests have been successfully unit tested, they are forwarded to the golden client and the QA system by delivery routes.

In this landscape client, dependant changes cannot be unit tested in a separate system.

© SAP AG E2E200 6-316



Transport StrategiesLesson 1: System Landscapes






© SAP AG E2E200 6-317




Parallel Projects

Synchronized Releases

Maintenance Cycles




Change Calendar


© SAP AG E2E200 6-318


Project Release Management

Implementation CIC 2.0

Trade Promotion Management

Rollout CIC 1.1Go Live

01 / 2006 01 / 200710 / 200607 / 200604 / 2006

Projects are defined by their release cycles. Any change, related to a project, moves synchronously from development through test to production or delivery.

© SAP AG E2E200 6-319


Object Conflicts and Object Dependencies

Project 1

Project 2

DEV

Conflicts

Project 1

Project 2

DEV

Dependencies

There are two types of problems when working with parallel projects. • Object Conflicts:

- This means that the same objects are contained in different projects. The project which is imported last, overwrites the objects of the other project. Therefore, the project which was imported first might not work anymore after the import of project 2.

• Object Dependencies: - Objects in different projects use each other, for example, a program in project 1 calls an

object included in project 2. If only one of the projects is imported into another system, it will fail. This problem is called cross-reference inconsistency.

© SAP AG E2E200 6-320


Cross-System Object Lock: Architecture 4.0

Test System Production System

Locks are performed on LIMU level for Workbench objects and on key level for Customizing objects

Development System 1Client1

…


…

SAP Solution Manager Cross-System Object

LockProjects

The Cross-System Lock is a feature of Change Request Management in SAP Solution Manager. It solves the problems caused when the same objects are part of different projects.

When a repository object or customizing entry is changed, a lock entry is written into a table in the Solution Manager. This lock is only removed at the point of import into production. When a second project tries to change the same object, an event is raised. Depending on the configuration, this event can be an error or only a warning.

The Cross-System Lock allows locking objects from the change up to the import into production.

Objects can be locked between projects, and urgent corrections within a maintenance project.

© SAP AG E2E200 6-321


Pre-Production System and Project Dependencies

DEV QAS PRDPRE

The Pre-Production System (PRE) has the current software/configuration state of production plus the next coming project

The next upcoming project cycle can be isolated in PRE

Cross Reference Errors can be detected and solved before they gointo Production

The solution for cross-referencing inconsistencies is a Pre-Production system. If the Pre-Production system has the current software / configuration state of production, the error can already be detected and fixed in Pre-Production.

© SAP AG E2E200 6-322


Parallel Projects – Best Practices

Projects in different areas can be done in parallel.

Projects in the same area should be done in sequence or handled as one project.

Good timing of projects from the beginning can reduce the effort.

Bundle several small projects into one.

Swap out long running projects into separate sandbox systems.

© SAP AG E2E200 6-323


Technical Realization: Usage of SAP IMG and CTS-Projects

Create IMG project

Activate CTS functionality

Assign Transport Requests to CTS project

SAP offers the use PROJECTS, to group comprehensive customizing and development activites.

With projects, you can define the customizing scope you want to cover. Please note that this is only important if you have several, simultaneous project activities. By activating a CTS project to work with your customizing project, you can link every change

request to a CTS project. The CTS project attribute of the change request lets you control the import of these changes into several target systems.

© SAP AG E2E200 6-324




Parallel Projects


Maintenance Cycles




Change Calendar


© SAP AG E2E200 6-325


Synchronized Release Deliveries

CIC1


01 / 200810 / 200707 / 200704 / 2007

CIC2.v1 CIC2.v2

TPM

TPM: Trade Promotion Management

CIC: Customer Interaction Center

There are fixed Go-Live dates for projects, for example, once per quarter. All projects can select one of the selected Go-Live dates. All projects that Go-Live together also go into the test phase together.

© SAP AG E2E200 6-326


Phase Control in cProjects and Change Request Management

Project cycleDevelopment phase(w/o or w/ release) Test phase

Go-live phase

Emergency correction phase

All Projects go together into the next project phase

Customer Interaction

Center

Test GoLiveTrade Promotion Mgt. Dev

SAP Solution Manager Project

cProject Programs Milestones

Each project cycle is controlled by it‘s phases. Projects that go-live together should also be tested together.

There should be a pre-production system, which all projects that are part of the next Go-Live can enter. All other projects have to stay in the development or unit test environment.

Project phases can be controlled by CTS status switches. They are set and controlled by the Change Request Management scenario. The project phases of several parallel projects can be synchronized, by using cProjects Program Management. Several Change Request Management projects are linked to one cProjects project.

© SAP AG E2E200 6-327


cProjects Project View

cProjects is a powerful project management and planning tool with interfaces to various R/3 modules (e.g. CO, HCM, …)

Milestones can be defined in cProjects. These milestones can be linked to the phases in Change Request Management. Only if certain milestones are approved in cProjects, can the phase be switched in the related Change Request Management projects.

A high level coordination team has to confirm before projects can go into the next phase. All other functions of cProjects are explained in dedicated cProjects training courses.

© SAP AG E2E200 6-328


Phase Shift in Change Request Management

It is possibile to switch the phases in the task-list. In this example, it will be switched from „Development with Release“ to „Test“. This is rejected by the system, because cProjects did not yet complete the required tasks. This must be completed first, because tasks may be still open in cProjects, which have to be completed urgently, before the phase switch can be completed. If the required tasks are completed in cProjects, then the phase can be switched to „Test“ in Change Request Management.

© SAP AG E2E200 6-329


Advantages of Release Deliveries

Advantages of Release Deliveries:Common regression testing for several projects at onceChanges in production only at certain pointsNo cross-reference dependencies with other projectsHigher stability in production

Advantages of Parallel Projects:No wait times for release deliveriesIndividual project duration of each project is possibleFaster realization, due to individual timing of each project

© SAP AG E2E200 6-330




Parallel Projects


Maintenance Cycles




Change Calendar


© SAP AG E2E200 6-331


Maintenance Cycles or Single Transports

… Maintenance Cycles

… Single Transports

01 / 2006 01 / 200710 / 200607 / 200604 / 2006

Advantages of the Single Transport Strategy: • Fast Realization of Changes • Only small changes to production at a time Easy to find the error • Disadvantage: No regression testing

Advantages of Maintenance Cycles: • No frequent changes in production • Regression and integration testing is possible (and needed) • Higher Stability in Production

© SAP AG E2E200 6-332




Parallel Projects


Maintenance Cycles




Change Calendar


© SAP AG E2E200 6-333


Change Calendar – What should be contained?

Which information should be contained?:Overview of current and planned projectsWhich projects are located in which systemsGo-Live dates of projects or transports

Where is it used?:Scheduling of new projects and change requestsAvoiding conflictsAligning implementation projects and maintenance tasks

© SAP AG E2E200 6-334


Development

Quality

Pre-Production

Production

1 2 3 4 5 6 7 8 9 10 11 12

Project2 Release

Development

Project3 Release

Development

Project4 Release

Development

Support Package

Implement.

Project2 Integration

testing


testing


testing

Project3 Acceptance

testing

Project1 Acceptance

testing

GL

ReleaseGL

ReleaseGL

GL GL

Maintenance

Critical error fixand associated update to

development When a critical error is discovered in

production, the error-fix is done in a separate “maintenance environment” and updated

manually to development system pipeline.

Example 1: Project Timeline

ReleaseGL

Project2 Acceptance

testing

This example shows the project plan for a roll-out project. The customer has chosen a sequential approach. When one project leaves the development system and goes into QA, the next project starts in Development.

The customer has a 4 system landscape and a maintenance system, which is refreshed by a production copy after each Go-Live.

This figure provides an overview of which project is on which system, at a certain point in time. This gives the program office a good overview when new projects need to be scheduled.

© SAP AG E2E200 6-335


Example 2: Maintenance Planning Calendar

Calender for 2006

January ISPIWP ICP February ISPIWP ICP March ISPIWP ICP April ISPIWP ICP May ISPIWP ICP June ISPIWP ICP1 Sun New Year´s Day [1] 1 Wed 1 Wed 1 Sat 1 Mon [18] 1 Thu 2 Mon [1] 2 Thu 2 Thu I S P

I C P 2 Sun 2 Tue 2 Fri 3 Tue 3 Fri 3 Fri I W P 3 Mon [14] 3 Wed 3 Sat 4 Wed 4 Sat 4 Sat 4 Tue 4 Thu 4 Sun Whitsunday (G)5 Thu 5 Sun 5 Sun 5 Wed 5 Fri 5 Mon Whitemanday (G) [23]6 Fri Epiphany (G) 6 Mon [6] 6 Mon [10] 6 Thu 6 Sat 6 Tue 7 Sat 7 Tue 7 Tue 7 Fri 7 Sun 7 Wed

8 Sun 8 Wed 8 Wed 8 Sat 8 Mon [19] 8 Thu 9 Mon [2] 9 Thu 9 Thu 9 Sun 9 Tue 9 Fri 10 Tue 10 Fri 10 Fri 10 Mon [15] 10 Wed 10 Sat 11 Wed 11 Sat 11 Sat 11 Tue 11 Thu 11 Sun 12 Thu 12 Sun 12 Sun 12 Wed 12 Fri 12 Mon [24]13 Fri 13 Mon [7] 13 Mon [11] 13 Thu 13 Sat 13 Tue

14 Sat 14 Tue 14 Tue 14 Fri Good Friiday (G) 14 Sun 14 Wed 15 Sun 15 Wed 15 Wed 15 Sat 15 Mon [20] 15 Thu Corpus Christi Day (G)16 Mon [3] 16 Thu 16 Thu I S P

I C P 16 Sun Easter Day 16 Tue 16 Fri

17 Tue 17 Fri 17 Fri I W P 17 Mon Easter Monnday (G) [16] 17 Wed 17 Sat

18 Wed 18 Sat 18 Sat 18 Tue 18 Thu I S P

I C P 18 Sun 19 Thu 19 Sun 19 Sun 19 Wed 19 Fri I W P 19 Mon [25]20 Fri 20 Mon [8] 20 Mon [12] 20 Thu 20 Sat DC Main (G) 20 Tue 21 Sat 21 Tue 21 Tue 21 Fri 21 Sun DC Main (G) 21 Wed

22 Sun 22 Wed 22 Wed 22 Sat 22 Mon [21] 22 Thu 23 Mon [4] 23 Thu 23 Thu 23 Sun 23 Tue 23 Fri 24 Tue 24 Fri 24 Fri 24 Mon [17] 24 Wed 24 Sat 25 Wed 25 Sat 25 Sat 25 Tue 25 Thu Ascension Day (G) 25 Sun 26 Thu 26 Sun 26 Sun 26 Wed 26 Fri 26 Mon [26]27 Fri 27 Mon [9] 27 Mon [13] 27 Thu 27 Sat 27 Tue 28 Sat DC Main (G) 28 Tue 28 Tue 28 Fri 28 Sun 28 Wed 29 Sun DC Main (G) 29 Wed 29 Sat 29 Mon [22] 29 Thu 30 Mon [5] 30 Thu 30 Sun 30 Tue 30 Fri 31 Tue 31 Fri 31 Wed

Leg endISP ReleaseDelivery Time QuarterEndClosing PCB M aintenance Delivery

ISW ReleaseDelivery Time YearEndClosing PCB Release Delivery

ICP ReleaseDelivery Time EM (for Emergency Request) Import I *P

M aintenanceDelivery ReleaseDelivery DB Reorg

This example shows the maintenance calendar of a solution consisting of a BW, CRM and ERP system.

Support Packages are imported from the end of January to beginning of February. Every second weekend, there are maintenance deliveries (Go-Lives of maintenance cycles). Sometimes, there are codefreezes due to quarter end activities. Projects can be incorparated into any maintenance cycle. This gives flexibility to the projects

as there are many Go-Live windows. This calendar shows 2 Best Practices: • All systems in a solution should be delivered with projects or maintenance cycles at the

same time. This is due to the dependencies of changes in different systems (see „transport dependencies“).

• The system owners are also responsible for maintenance. First, the maintenance is planned. Then, the implementation projects consider the maintenance plan in their project schedule.

© SAP AG E2E200 6-336


Project Overview in SAP Solution Manager

This screenshot shows transaction SOLAR_PROJECT_ADMIN. It shows all projects, currently planned in the SAP Solution Manager. If you double click on the projects, you see more details, for example, begin and end dates, etc.

© SAP AG E2E200 6-337


Project Overview in Change Request Management

This screenshot shows transaction /TMWFLOW/CMSCONF in Change Request Management. It shows all projects of type implementation. Furthermore, you can see which project phase they are in and which systems the projects are located in.

© SAP AG E2E200 6-339








Customizing Synchronization

Synchronization of Transports

Special Dependencies


© SAP AG E2E200 6-340


ERP-DEV ERP-QAS ERP-PRD

Consistent Customizing between Systems

CRM-DEV CRM-QAS CRM-PRDreplicate

Applications require consistent data between product instances, like conditions in ERP and CRM.

Data replication takes place at Save or Release Task time. Changes are synchronized in both landscapes within the project cycle context.

In this example, customizing settings between ERP and CRM must be kept synchronous. For this, SAP Solution Manager provides a customizing distribution scenario. This will be described on the next slides.

© SAP AG E2E200 6-341


sourcesettings target

settings

Sync

hron

izat

ion

Gro

up

Customizing Distribution: Overview

Customizing dataR/3DEV

R/3QAS

R/3PRD

CRMDEV

CRMQAS

CRMPRD

...DEV

...QAS

...PRD

SAP SolutionManager

with Customizing Distribution

Transport

Transport

Transport

Transport

Transport

Transport

You often need to synchronize selected customizing settings in various systems in a system landscape. You can use Customizing Distribution to synchronize customizing settings in a source system, such as, SAP R/3, with the customizing settings in target systems, such as a SAP CRM system in a SAP system landscape.

Customizing Distribution uses transport requests to transport customizing changes from development systems to the quality assurance and production systems. Customizing Distribution is performed between development systems only.

Customizing objects (Synchronization Objects) that should be synchronized between various SAP components are predefined.

When you create a synchronization group, you can select synchronization and other customizing objects using the Synchronization Group Editor.

When you change customizing settings of an object in the source system, Customizing Distribution begins transferring the changes to the target system.

You use Customizing Distribution to transfer customizing changes made in a SAP R/3 development system, to other development systems in the system landscape. For example, you can use Customizing Distribution to:

Download selected customizing from a SAP R/3 Enterprise to a newly-installed SAP APO system.

Synchronize customizing in an HR and a non-HR system and use ALE distribution in a stand-alone HR.

© SAP AG E2E200 6-342

Synchronize customizing in a SAP R/3 Enterprise and a SAP CRM system, because there are business processes that run in both SAP R/3 and SAP CRM.


Automatic Customizing Distribution in Detail

SAPSolutionManager

SAPERPDEV

SAPCRMDEV

SAPERPQAS

SAPERPPRD

SAPCRMQAS

SAPCRMPRD

Time zonesTransport zonesCurrenciesCustomer groupsProduct groups...

Save customizing intotransport request1

Notify Solution Managerabout customizing changes

2

Map source to target customizing, after importing changes

3

Send target settings to target system4

Time zonesTransport zonesCurrenciesCustomer groups...

Write target settings into transport request5

Log

Generate distribution logs6

Save customizing into a transport request. Notify Solution Manager about customizing changes. Map source into target customizing, after importing changes. Send target settings to target system (via BC Set). Write target setting into a transport request. Generate distribution log.

© SAP AG E2E200 6-343


How To Set Up Customizing Distribution

Define customizing distribution scenario:What? – Synchronization groupFrom where to where? – Source and target systemsAt what times? – Distribution types/frequency

Overview distribution options:At transport recording (for immediate testing)At transport release (after successful testing)Timed distribution (transfer of customizing only at pre-defined times, e.g. at night or at weekends)Initial distribution (complete copy of selected customizing objects)

Choose a distribution type or types: • Timed Distribution: Customizing Distribution is scheduled in the background, at the times

you specify. • Synchronization by Transport Changes: Each time a transport request belonging to the

project is changed, the relevant customizing is distributed. • Synchronization by Transport Release: Each time a transport request belonging to the

project is released, the relevant customizing is distributed. • Initial Distribution: Settings from customizing tables from SAP R/3 are written in

customizing tables in the target system without foreign key checks.

© SAP AG E2E200 6-345


TransportLandscapeCRM

TransportLandscapeEP

TransportLandscapeBI

TransportLandscapeERP

TransportLandscapePI

Development Landscape QALandscape

ProductionLandscape

DevelopmentEnvironment

SE80DS & DI

Portal ContentAdministrator

System

mySAP ERP

mySAP CRM

System

mySAP ERP

mySAP CRM

EnterprisePortal

System

mySAP ERP

mySAP CRM

EnterprisePortal

BI

EnterprisePortal

BI BI

ProcessIntegration

(XI)

ProcessIntegration

(XI)

ProcessIntegration

(XI)

DS & DI

SE80

SE80Integration

Builder

SE80DS & DI



DS & DI

Change Request Management in a mySAP Business Suite Solution

Change Request Management can handle dependent transports in different systems. In this example the Solution Manager Project comprises a several SAP system. The systems

have dependent transports. All transports for the whole solution are bundled by the umbrella of the Solution Manager project. When the project goes live all transport requests that belong to the same Solution Manager project are imported at the same time. So all dependencies are considered automatically.

© SAP AG E2E200 6-346


Solution Manager Project Comprises Several Transport Tracks

Solution Manager Project

– Development Environment- ERP

Transport Request1Transport Request2

- CRMTransport Request3

- BWTransport Request4

– Quality Assurance Environment- ERP - CRM- BW

– Production Environment- ERP - CRM- BW

Change Request Management can handle dependant transports in different systems. In this example the Solution Manager Project comprises an ERP, CRM and BW system. The

systems have dependant transports. All transports for the whole solution are bundled under the umbrella of the Solution Manager project. When the project goes live all transport requests, that belong to the same Solution Manager project, are imported at the same time. Therefore, all dependencies are considered automatically.

© SAP AG E2E200 6-348


ERP-DEV ERP-QAS ERP-PRDConfig

Data Consistency between Systems: CRM Delta Load

CRM-DEV CRM-QAS CRM-PRDConfig

Master Data

Master Data

Master Data

Master Data

Config

Config

1

2

Applications require consistent master data and condition data between product instances, like ERP and CRM.

The delta load must be performed before the configuration changes are imported.

Applications require consistent master data and condition data between product instances, like ERP and CRM or APO.

The CRM delta load must be performed before the configuration changes are imported

© SAP AG E2E200 6-349


ERP-DEV ERP-QAS ERP-PRD

Data Consistency between Systems: OLTP and OLAP

BI-DEV BI-QAS BI-PRD

Data Source Data Source

Transfer Rules Transfer Rules

Replicated DS Replicated

1

2

3

A

C

B

Applications require consistent interface data between OLTP extractor and OLAP transfer structure.

The data structure must be imported into the OLTP system, before the transfer structure in the OLAP system is to be imported

The BI system wants to receive data from the ERP system. For this, the following steps have to be performed: • Create data source in the ERP-DEV system (e.g. transaction RSO2). • Replicate the data source into the BI-DEV system. • Create Transfer Rules in the BI-DEV system.

When it comes to transport into the QA environment, the following steps must be performed in the right order: • Transport data source in the ERP-QAS system. • Replicate data source into the BI-QAS system (there exist transport objects for data source

replication). • Transport transfer rules into the BI-QAS system.

© SAP AG E2E200 6-351


Critical Transport Objects

Uncritical Objects:Forms, e.g. SAP ScriptsAuthorizationsSimple Customizing (without generation of repository objects)

Critical Objects:Customizing with generation of repository objects (e.g. LIS)Report sourcesDictionary Objects

Very Critical Objects: Frequently used Sources (e.g. User Exits)Dictionary Objects which must be converted (esp. Big tables like vbap, coep)Dictionary Objects which are frequently used by other objects (komk, komp, t001w)

Critical Transport Objects have a long import runtime. During the time of the import, inconsistencies, dumps and, in rare cases, even logical errors (wrong results) can occur in the system. Therefore, critical transport objects should be known. Imports that contain critical transport objects should be imported during downtime or, at least, during times of low system usage.

© SAP AG E2E200 6-352


Critical Business Objects

Critical Business Objects are:SD condition tablesUser exitsComplete development classes in business critical areas

Business critical objects are central objects, which are used by many applications or very critical applications. If they are changed it might have severe side-effects in many areas. Therefore, an extended test is needed before these objects are imported into production.

The list contains some business critical objects.

© SAP AG E2E200 6-353


Checking for Critical Objects

Object listR3TR PROG ZABAPR3TR TABU ZTABLE...............






Object listR3TR PROG ZABAPR3TR TABU ZTABLE...............DEV: 0

QAS: 7PRD: 3

Request1 DEVK9000162 DEVK9000183 DEVK9000204 DEVK9000235 DEVK9000026 DEVK9000337 DEVK900035


Table of critical objects

Compare critical objects

R3TR TABU ZTABLE

To check if the change requests in an import queue contain critical objects that should not be imported into the target system, go to the Import Overview and choose Queue Check Critical objects. The object lists of the requests are checked to see if they contain critical

transport objects. The results are displayed in a hierarchical list. Requests containing critical objects are marked with the appropriate icon. The critical objects are highlighted in color.

Before performing this check, you need to have maintained the critical transport objects in the SAP System whose import queue you want to check for critical objects.

To display or maintain the critical transport objects defined for the relevant SAP System, call transaction STMS in the SAP System for which you want to display/maintain the critical objects. Choose Overview Imports Extras ��Critical transport objects.

Since the table of critical objects is a Customizing table, it should be maintained in the development system, and then transported to other SAP Systems from there.

The TMS check for critical transport object is executed at the time of the import into production.

© SAP AG E2E200 6-354


Approval of Critical Objects in Change Request Management

Change Request Management also provides approval for critical objects. When a critical object is contained in a transport of the change transaction, no export is possible unless the change manager approves the critical object.

The benefits of this procedure, compared to the TMS check for critical transport objects are: • Customizing entries can also be marked as critical. • The check is performed at the time of export from the development system. This gives the

organization many options on how to deal with that critical object. If a critical object is only detected at the time of the import, it is often difficult to postpone a scheduled Go-Live.

Critical objects can be configured in transaction is /TMWFLOW/CMSCONF.

© SAP AG E2E200 6-355


Downtime Aspects

Import mass changes and single changes that contain critical objects during downtime or, at least, during times of low system usage.

Switch off background jobs.

Use Import ALL instead of Import Single.

Create Merge Transports, as described in note 139513.

Set GENERATION = FALSE in TP_DOMAIN_<SID>.PFLNo generation of programs and screensStart SGEN for transport request (uses several processes) or start the report RSGENINVLAS

Business Warehouse :Long Import Times due to long running After-Import-MethodsDo not allow Data Load during Imports, Queries might be okayImport Single should be used

During the time of the import inconsistencies, dumps and, in rare cases, even logical errors (wrong results) can occur in the system. Therefore, we recommend to import mass changes and single changes that contain critical objects during downtime or, at least, during times of low system usage.

There are some possibilities to reduce the import time of big imports. The best practices are listed on this slide.

© SAP AG E2E200 6-356


Unit Summary


Understand the limitations of the 3 system landscape and the benefits of advanced transport topologies

Understand the different client roles

Describe pros and cons of parallel projects, synchronized releases and maintenance cycles

Know how to manage transport dependencies

Be aware of critical objects

© SAP AG E2E200 6-358

Exercises

Unit: Transport Strategies

In this exercise, you can test your knowledge on system landscapes and transport strategies


6-1 What are risks when using the Import Single strategy?


True False

Inconsistencies between workbench and customizing requests

Cross-reference inconsistencies due to forgotten transports

Long import times of individual transport requests

Wrong transport sequence

6-2 What is recommended when several parallel implementation projects with different

GoLive dates are running in one transport landscape?


Global rollout landscape

Separate development client for each project

© SAP AG E2E200 6-359

Preproduction system

6-3 What are advantages of a phased system landscape?


True False

Faster realization of business requirements

Implementation projects and maintenance tasks can be separated

No codefreeze required

Clean environment for emergency corrections

© SAP AG E2E200 6-360

Solutions

Unit: Transport Strategies

6-1 What are risks when using the Import Single strategy?


True False

O X Inconsistencies between workbench and customizing requests

X O Cross-reference inconsistencies due to forgotten transports

O X Long import times of individual transport requests

X O Wrong transport sequence

6-2 What is recommended when several parallel implementation projects with different

GoLive dates are running in one transport landscape?


O Global rollout landscape

O Separate development client for each project

X Preproduction system

© SAP AG E2E200 6-361

6-3 What are advantages of a phased system landscape?


True False

O X Faster realization of business requirements

X O Implementation projects and maintenance tasks can be separated

O X No codefreeze required

X O Clean environment for emergency corrections

© SAP AG E2E200 7-363

© SAP AG 2007

Content:

Change Request Management Overview

Project and Release Management

Change Requests

Maintenance Activities


Tools

Best Practices

Change Request Management: Unit Content

© SAP AG E2E200 7-364

© SAP AG 2007

Unit Objectives


Define the Change Request Management business process

Explain how to use the SAP Solution Manager system for the Change Request Management scenario

Describe the various elements of Change Request Management as part of SAP Solution Manager

Describe SAP’s best practices in transport management which are implemented in the SAP Solution Manager

© SAP AG E2E200 7-365

© SAP AG 2007

Change Request Management Unit Overview Diagram


Lesson 1: Change Request Management Overview

Lesson 2: Project and Release Management

Lesson 3: Change Requests

Lesson 4: Maintenance Activities

Lesson 5: Implementation Projects

Lesson 6: Tools

Lesson 7: Best Practices

© SAP AG E2E200 7-366

© SAP AG 2007

Story Line: Change Request Management

Effective application management is essential for companies to stay ahead of competition.

SAP’s scope of application management includes all types of application changes:

Business process changes, implementation and upgrade projectsPeriodic maintenance Emergency corrections

Change Request Management strengthens the strategy of SAP Solution Manager, as SAP‘s application management platform which:

Ensures reliabilityReduces Total Cost of Ownership and increases Total Solution ValueBridges the gap between business requirements and IT administration

© SAP AG E2E200 7-367

© SAP AG 2007

ITIL Change Management Process

Create RfC

Accept: Filter RfC

Classify: Category and Priority

Urg

ent

Cor

rect

ion

Plan: Impact und Resources

Con

figur

atio

n M

anag

emen

t pro

cess

es th

e da

taan

d co

ntro

ls th

e st

atus

of t

he C

Is

Fallb

ack

Evaluate and close

Urgent?

Coordinate

Develop

Test

Implement

Control

yes

no

Correct

Rejected: New RfC

yes

no

What is ITIL®?

Acronym for the "IT Infrastructure Library" guidelines developed for the British government De-facto global standard in the area of service management Contains comprehensive, publicly accessible documentation on the planning, provision and

support of IT services Provides the basis for improving the use and effect of an operationally deployed IT

infrastructure Describes the architecture for establishing and operating IT service management. The ITIL books are best practice guidelines for service management, with the guidelines

describing what rather than how. Service management is tailored to the size, the internal culture and, above all, the requirements of the company. The impartial view of the external consultant may help to break away from the rigid structures.

© SAP AG E2E200 7-368

© SAP AG 2007


Three tiers of Change Request Management

Management of all change requests

Change request categorization


Approval workflow

Status reporting

cProjectAdministration

Change Admin

Development & Customizing Infrastructure

Workbench Organizer

Transport Management

Transport scheduling

Transport tracking

Change LogisticsProject Management

Project Administration

Project documentation

Project Blueprint & Configuration

Test Management

Learning Management

© SAP AG E2E200 7-369

© SAP AG 2007

Change Request Management – Roles in a Nutshell

… categorizes, approves and monitors Change Requests.

… is the Steering Committee in the Change Management process.

… implements a change and hands over to the Tester.

… tests a change, sets status in the Change Document.

… takes care of software logistics.

… creates an Service Message or a Change Request directly.

Developer

Requestor

Tester

ChangeManager

IT Operator


Change Advisory Board

… handles the Service Message and creates a Change Request.

Responsibilities:

Requestor: To describe the change required in detail. To identify the priority of the request and describe why the capability is needed, and to identify the impact if the desired capability is not provided.

Service Desk Employee: To act as the central point of contact between the User and IT Service Management. To handle Incidents and requests, and provide an interface for other activities, such as Change, Problem, Configuration, Release, Service Level, and IT Service Continuity Management.

Change Manager: • To ensure that standardized methods and procedures are used for efficient and prompt

handling of all Changes, in order to minimize the impact of any related Incidents on service.

• To accept, or reject Change Requests. • To monitor the Change Management process. • To release Changes for production.

Developer: To implement and document a Change in the development system, to provide adequate test cases, or update existing ones.

© SAP AG E2E200 7-370

Tester: To follow instructions in the relevant test cases and make sure that the Change has been promoted correctly into the consolidation environment. If a Change causes incidents in the consolidation environment, it is the testers duty to set the Change back into development.

IT Operator: To provide support if the Change Management process is impeded in any way. To import the Change into the production environment.

© SAP AG E2E200 7-371

© SAP AG 2007








Lesson 6: Tools


© SAP AG E2E200 7-372

© SAP AG 2007

Projectcreated in cProjects

SAP SolutionManagerproject


Projectcycle

transaction

cProjects

Project cycle

task list

Release Management & Change Request Management

IMG project

IMG project

...

Physical (development)

systems

CTSprojectCTS

projectCTS

project

Logical systems(clients)

CTSproject

CTSprojectCTS

project

...

...

TransportRequest

The Solution Manager project is represented as an IMG project in each satellite system and a CTS project in each satellite system client.

For each Solution Manager project, a project cycle is generated, which is represented by a task-list for managing the technical administration, and a cycle transaction for managing the organizational administration of the project cycle.

Transport requests are only managed by the project cycle. The project assignment of each transport request is mandatory

The Solution Manager project can be extended by cProjects to manage project phases and project tasks. cProjects allow the management of inter-project dependencies.

© SAP AG E2E200 7-373

© SAP AG 2007

Release Management with Change Request Management

SAP Solution Manager projects can be extended by adding project cycles, which control project phases.

Project phases determine whether or not transport requests can be created, released, or imported.

Project phases are visible in the blueprint and configuration transactions.

cProjects can be used to extend project management capabilities and to manage multiple phase-specific projects.

This is the IT Infrastructure Library (ITIL) definition of release management. ITIL is the de-facto global standard for service management. For more information, go to www.itil.org

© SAP AG E2E200 7-374

© SAP AG 2007

SAP Solution Manager Projects and Project Cycles

SAP Solution Manager project

Project cycleDevelopment phase(w/o or w/ release) Test phase

Go-live phase

Emergency correction phase

cProject

Each project cycle is controlled by it‘s phases. Project phases are static and linked to each cycle

Each project cycle phase offers certain functions which differ according to the project type.

© SAP AG E2E200 7-375

© SAP AG 2007


Change Request Management – Cycle Management

CycleTransaction

DEV

QAS

PRD


Controlled transportsCha

nge

Req

uest

Man

agem

ent

ChangeManager

Project Cycle

Cycle TaskList

The project cycle is an abstraction layer, representing the fix phase structure of a cycle, that cannot be changed.

The cycle task-list represents the system landscape tracks the tasks to be used by an IT operator or IT administrator for managing project related IT activities, especially imports. Custom task-list templates with additional tasks can be created by customers.

The cycle transaction represents the service request for managing the phase changes. Documentation, additional status, notification, electronic signatures etc. can be managed from within the cycle transaction. Phase shifts should be done from within the cycle transaction but not from within the cycle task-list, since additional activities and status can only be managed from within the service request.

© SAP AG E2E200 7-376

© SAP AG 2007

Project Cycle I

SAP Solution Manager projects define the project landscapes

Project landscapes contain one or more logical components

Logical components incorporate logical systems that have the following system role types:

Source System (development systems and starting systems)Target System (any system between the development and productionsystems)Production System (production systems and ending systems) Single System (evaluation systems without connection to a transport route) Post-Processing System (retrofit systems)

IMG and CTS Projects collect changes:An IMG project represents an SAP Solution Manager project in onedevelopment systemA CTS Project represents an IMG project in one client

When a project cycle is being generated, all logical components are taken into account as well as the transport routes of all systems.

Tracks are being generated for each development system that matches to a system of role type ‚Source System‘ in the logical component and as a source of a consolidation route in TMS. Each track is represented by one CTS project.

© SAP AG E2E200 7-377

© SAP AG 2007

Project Cycle II

Project cycles generate the phase instance of a project

Only one active cycle can exist simultaneously for each projectProject Cycles:

control project phasescontrol whether or not transports are created, exported, or importedincorporate all logical systems that belong to a projectcan be closed after the go-live phase, or reset to the “In Development”phase

The project types that are supported are:Template projectImplementation projectUpgrade projectMaintenance project (special semantics apply and will be explained later)

Projects of type maintenance are represented by transaction type SDMN Projects of type implementation, upgrade and template are represented by transaction type

SDDV

© SAP AG E2E200 7-378

© SAP AG 2007








Lesson 6: Tools


© SAP AG E2E200 7-379

© SAP AG 2007


Change Request Management – Change Request

Serv

ice

Des

kC

hang

e R

eque

st M

anag

emen

t

ChangeTransaction

SDMJ / SDHF

Change RequestSDCR

ChangeManager

Service Message

SLFNRequester


Feedback

A Change Request has no corresponding Project. With the approval process a project type is assigned to the Change Request. Approving a

Change Request results in a change transaction for this type of project.

© SAP AG E2E200 7-380

© SAP AG 2007

Creating and Approving a Change Request

An approved change request results in the creation of a change transaction.The entry in the IBase field is used to identify the production system that the changeis required for.The entry in the Subject field is used to identify the project type and the change process type.

Project types: TemplateImplementationUpgradeMaintenance

Change types: Urgent Correction (only for maintenance projects)Normal Correction (for any project type)Administration Activity (for any project type)

Customizable Fields: Category, Priority, Reference, Date, ProductsExtended general Customizing (project): Event-driven notifications, feedback, cost management, extended custom fields and custom tabsExtended change request-specific Customizing (project): Text profiles, activity profiles, status schema, transaction types

Implementation, Upgrade and Template Projects: When a change request for a Normal Correction is being approved, a project cycle must be

linked to it. The project cycle must be in the project phase development w/ release or development w/o release.

Maintenance Project: In a maintenance project, Normal Corrections can be approved during all phases, starting with

development w/o release up to Go-Live. In addition, Urgent Corrections can also be approved during all phases, starting development

w/o release up to Go-Live.

© SAP AG E2E200 7-381

© SAP AG 2007

Approval Process: Create and Accept RfC

Create RfC

Accept: Filter RfC


Urg

ent

Cor

rect

ion

Plan: Impact und Ressources

Urgent? yes

Rejected: New RfC

no

It is not my fault someone else was responsible for it!

That is not what I have required!

Create RfC:

Provide a tool so that no change requests are lost Accept: Filter RfC

• Assign RfC to a business process • Is the requestor authorized? • Is it an RfC or an incident?

Assign a responsible Change Manager Check if there are similar requests • Bundle and consolidate them

Check if there are ongoing changes in this area Tools: • Change Request Reporting

© SAP AG E2E200 7-382

© SAP AG 2007

Approval Process: Classify and Plan RfC

Create RfC

Accept: Filter RfC


Urg

ent

Cor

rect

ion

Plan: Impact und Ressources

Urgent? yes

Rejected: New RfC

no

I had other priorities-that's why I‘m too late!

Why didn't you ask me earlier!-Production can‘t assemble it!- Service can‘t support it! - Sales thinks it’s great new technology but sees no market

Classify: Category and Priority:

Priority: • Impact to the business process ($) • Due date (e.g. month end closing)

Category: • Depends on the priority • Which cycles exist

- Urgent correction - Normal Correction - Project Request

• Definition of the Transaction Type - Administrative - Transport

• Identify the components and business processes which are involved Tools: • Change Calendar • Solution Directory (Business Process Library)

© SAP AG E2E200 7-383

Plan: Impact and Resources • Complexity of change • Business areas affected • Critical objects check • Regression test required

© SAP AG E2E200 7-384

© SAP AG 2007

System-Demo

System-Demo

© SAP AG E2E200 7-385

© SAP AG 2007

Exercise

Exercise

© SAP AG E2E200 7-386

© SAP AG 2007


Change Request ManagementLesson 1: Change Request Management Overview





Lesson 6: Tools


© SAP AG E2E200 7-387

© SAP AG 2007


Change Request ManagementLesson 4: Maintenance Activities

Administration Activities

Maintenance Cycle

Urgent Correction

Normal Correction

Test Message

Maintenance Project

© SAP AG E2E200 7-388

© SAP AG 2007

Maintenance Project: Definition

The maintenance project is prerequisite for production support.

A maintenance project manages maintenance cycles for as long as is defined by the project lifecycle.

The maintenance cycle consistently distributes any maintenance or urgent correction change to any system of the project landscape.

One maintenance project can have multiple maintenance systems assigned to it, including the corresponding transport routes (one logical system for Workbench requests and one logical system for Customizing requests, for example). A maintenance cycle belongs to just one maintenance project.

© SAP AG E2E200 7-389

© SAP AG 2007

Harmonizing Maintenance Activities

Urgent Corrections(independent of MC)

NormalCorrections

Maintenance CycleDevelopment

(w/o or w/ release) Test Go-LiveEmergency Correction

cProject

Test messages(during integration test)

SAP Solution Manager Project (Maintenance Project)

Maintenance Cycle

Harmonization Harmonization Harmonization

The maintenance project is a prerequisite for production support. It is the central unit for all information, such as, logical component and system landscape, and

the high level project plan. It closes the gap between planning and software logistics: • SAP Solution Manager project • IMG project • CTS project

A maintenance cycle belongs to just one maintenance project.

© SAP AG E2E200 7-390

© SAP AG 2007




Maintenance Cycle

Urgent Correction

Normal Correction

Test Message

Maintenance Project

© SAP AG E2E200 7-391

© SAP AG 2007

Maintenance Cycle: Definition

A maintenance cycle is the period of time in which you:

make changes in maintenance systems

include these changes in new transport requests

import these requests into follow-on systems for testing

At the end of a maintenance cycle, all transport requests are imported into the production system at the same time. Subsequently, the maintenance cycle can be closed manually and anew one can be created, if necessary (but only in compliance with the rules of the change requests that belong to the maintenance cycle).

© SAP AG E2E200 7-392

© SAP AG 2007




Maintenance Cycle

Urgent Correction

Normal Correction

Test Message

Maintenance Project

© SAP AG E2E200 7-393

© SAP AG 2007




NormalCorrections

cProject



w/o or w/ release Test Go-LiveEmergency Correction

Urgent corrections are fast changes that have to be imported into the production environment as quickly as possible.

An urgent correction can be described as the smallest subproject of a broader maintenance project cycle.

Urgent Corrections can be performed during the maintenance project phases ‚Development w/o release‘ up to ‚Emergency Correction‘.

Urgent Corrections can be approved and developed but not exported during Go-Live Phase.

© SAP AG E2E200 7-394

© SAP AG 2007


Change Request Management – Urgent Correction

Change Request

Service Message

Developer

Requester

Tester

ChangeManager

DEV

IT Operator

QAS

PRD




Serv

ice

Des

kC

hang

e R

eque

st M

anag

emen

t

ChangeDocument Task

List

Feedback

Maintenance Cycle

An urgent correction is represented by a singular task list that is created when an urgent correction is being generated during approval time.

An urgent correction task-list is being closed when the urgent correction is being closed. An urgent correction can be described as the smallest subproject of a broader maintenance

project cycle. Technically, an urgent correction is managed by “import subset” and is automatically merged

into the current open maintenance cycle.

© SAP AG E2E200 7-395

© SAP AG 2007

System-Demo

System-Demo

© SAP AG E2E200 7-396

© SAP AG 2007




Maintenance Cycle

Urgent Correction

Normal Correction

Test Message

Maintenance Project

© SAP AG E2E200 7-397

© SAP AG 2007




NormalCorrections

cProject





The Normal Correction relates to the life cycle of the project. As of SAP Solution Manager 4.0 SP6 the transaction type for the Normal Correction will be

SDMJ. It is an optimization of the Normal Correction (SDMI), which is already available. Each project can have as many Normal Corrections as required. A Normal Correction phase depends on the phase of the project cycle phase. • For Maintenance Projects Normal Corrections can be approved during the phases

Development w/o release up to Go-Live. • From the Test phase up to Go-Live, no export of transports is possible.

Normal Corrections allow development up to unit testing: • Transport requests can be created • Transport tasks can be created • Test transports can be created • Test transports can be exported • Development can be closed • Unit test can be performed • Unit test can be confirmed

© SAP AG E2E200 7-398

© SAP AG 2007

Normal Correction

The normal correction relates to the life cycle of the project

Each project can have as many normal corrections as required

A normal correction can be shared by multiple developers, and multiple transport requests and transport tasks can be created

A normal correction phase depends on the phase of the project cycle

Normal corrections can only be distributed by ‘import project’Transport requests/tasks can be created and exported from within the service requestProject exports and imports can be managed by the maintenance task-list

© SAP AG E2E200 7-399

© SAP AG 2007


Change Request Management – Normal Correction

Change Request

Service Message

Developer

Requester

Tester

ChangeManager

DEV

IT Operator

QAS

PRD




Serv

ice

Des

kC

hang

e R

eque

st M

anag

emen

t

ChangeDocument

Feedback

Maintenance Cycle

A Normal Correction is generated as a follow-up transaction by the approval activity. Normal Corrections are directly linked to a project cycle transaction and project cycle task-

list. From within a Normal Correction, the creation of a transport request and transport task and the

release of related transports are controlled by the Change request/Normal Correction. Imports are done by means of import projects from within the cycle task-list.

A Normal Correction can be shared by multiple developers and multiple transport requests and transport tasks can be created

© SAP AG E2E200 7-400

© SAP AG 2007

Import buffer Import buffer

Consistent Normal Corrections in a Project Cycle

DEV QAS PRD

Legend:

Normal CorrectionsTest Transports (Transport of Copies)

Normal Corrections are exported as test transports, which are performed as transports of copies.

Up to status consolidated , only test exports are possible: The system generates and exports transports of copies from the workbench or customizing requests of the activity.

When status is transferred to consolidated’, all transport requests will be exported and put in the queue. • No new transport requests can be created for the Normal Correction.

Normal Corrections are imported by using the “import project” method from within the cycle task-list • All exported transport requests are imported using the “import project” method • Transport requests can be imported once into each project system that has the role type

target or production • During Status ‘in Development’ only test transports can be performed • Test transports are not filled, but are transported as transports of copies into the

consolidation buffer • Function groups within the task list must be unlocked by the administrator before they can

be performed Imports with the “Import Project” method into systems that have the role:

© SAP AG E2E200 7-401

• type target can only be performed at the beginning of the cycle phase ‘Development w/ release’.

• type production can only be performed during the cycle phase ‘Go-Live’.

© SAP AG E2E200 7-402

© SAP AG 2007

Transport buffer Transport buffer

Consistency of Urgent Corrections and Maintenance Activities

DEV QAS PRD

Legend:

Maintenance ActivitiesUrgent CorrectionConsolidated Transport

Urgent Corrections are transported individually, meaning that there is no dependency to other corrections.

They are imported using the transport method import subset and stay in the transport buffer after import.

Urgent Corrections are propagated into other systems at the end of phases in the Maintenance Cycle, together with the Normal Corrections using the transport method import project.

For Normal Corrections, the Import into the follow-on systems takes place in the historical sequence.

© SAP AG E2E200 7-403

© SAP AG 2007

Differences Between Urgent and Normal Corrections

Developer and tester must be different persons.

A violation of the separation of functions is only a warning.

Transports can be propagated directly into the follow-on systems, but remain in the transport buffer.

Transports are exported and imported in accordance with the phases of the maintenance cycle.

Transports are generated automatically.

Transports have to be created manually, using the actions of the change transaction.

An individual task list is used.No individual task list. The task list of the maintenance cycle is used.

Urgent CorrectionNormal Correction

© SAP AG E2E200 7-404

© SAP AG 2007

System-Demo

System-Demo

© SAP AG E2E200 7-405

© SAP AG 2007

Exercise

Exercise

© SAP AG E2E200 7-406

© SAP AG 2007




Maintenance Cycle

Urgent Correction

Normal Correction

Test Message

Maintenance Project

© SAP AG E2E200 7-407

© SAP AG 2007




NormalCorrections

cProject





Change requests cannot be exported during the test phase. No exports are possible in maintenance projects. Furthermore, no new Change Requests can be created in implementation projects.

A test message allows a tester to contact a developer, and to create and export a transport request within the test phase of a project cycle.

Phase „Test“ for a Maintenance Cycle: • Test Messages can be created • New normal corrections can be created but not exported any more. • Urgent corrections can still be created and also propagated up to going live.

Test Messages must be released closed before status Emergency Correction is set.

© SAP AG E2E200 7-408

© SAP AG 2007


Change Request Management – Test Message

CycleTransaction

Developer

Tester

ChangeManager

DEV

QAS

PRD



Cha

nge

Req

uest

Man

agem

ent

Test Message Cycle

Task-list

Project Phases

A test message is supposed to be created by a tester, but only in the test phase of a certain project: • Log on to development system • Create transport request • Create transport task • Release transport request

Test Messages can be created by using transaction CRMD_ORDER or transaction TEST_CREATE

The test phase represents the integration test phase within a project cycle. Corrections are therefore, not directly linked to a change request but to the complete project cycle.

The Change Manager, Quality Assurance Manager or Project Manager creates the ability to create test messages for a certain project when she/he switches a phase to TEST. Test messages do not require an approval.

The import of corrections into test systems must be performed by the IT Operator by means of periodic running import jobs f.i.

© SAP AG E2E200 7-409

© SAP AG 2007




Maintenance Cycle

Urgent Correction

Normal Correction

Test Message

Maintenance Project

© SAP AG E2E200 7-410

© SAP AG 2007



Synchronizing

Maintenance Cycle

Synchronizing Synchronizing

Development(w/o or w/ release) Test Go-LiveEmergency

Correction

cProject

Admin.

Administration messages can be created during all operational phases of a project and allow logon to any project landscape system.

© SAP AG E2E200 7-411

© SAP AG 2007


Change Request Management – Administration Message

Change Request

Service Message Requester

ChangeManager

DEV

IT Operator

QAS

PRD

Service Desk

Employee

Serv

ice

Des

kC

hang

e R

eque

st M

anag

emen

t

AdminMessage Cycle

Task-list

Feedback

Project Phases

Administration messages must be approved by a change request, unlike test messages that are open to be performed whenever a project cycle phase is being switched to test..

The administration message is linked to the cycle task-list and custom tasks can be added to the cycle task-list template.

Administration messages allow administration activities in the systems of a project landscape • Logon to target systems • Documentation of administration changes

Additional tasks can be included in the cycle task list and in the activities of the administration message

© SAP AG E2E200 7-412

© SAP AG 2007








Lesson 6: Tools


© SAP AG E2E200 7-413

© SAP AG 2007

Harmonizing Project Activities

SAP Solution Manager Project (Imp./Upgrade/Temp.Project)

NormalCorrections

Project CycleDevelopment

(w/o or w/ release) Test Go-LivePreparation for Go-Live

cProject


Admin


For Implementation, Upgrade and Template Projects, Normal Corrections can be only approved during the project phase development w/o release and development w/ release.

© SAP AG E2E200 7-414

© SAP AG 2007








Lesson 6: Tools


© SAP AG E2E200 7-415

© SAP AG 2007


Change Request ManagementLesson 6: Tools

Retrofit

SAP Change Manager

Cross System Object Lock

Critical Object Approval Process

Change Request Management Reporting

© SAP AG E2E200 7-416

© SAP AG 2007

Quality

Change Request Managementconfigured

Data Collector job is scheduled


Development Productive

Poll via RFC

Poll via RFC

Poll via RFC

Change Management Reporting - Requirements

Change Management Reporting in SAP Solution Manager requires that the monitored systems are included in projects for which Change Request Management is activated.

Data from satellite systems is collected every hour (default setting), and after each import that is scheduled by means of the task list

Information on transported objects can be collected on demand. Object Reporting increases the data volume in the SAP Solution Manager if large system landscapes are managed.

© SAP AG E2E200 7-417

© SAP AG 2007

Typical Questions to be answered by Change Request Management Reporting

Which change requests are in process/completed...?By status, type, next steps , maintenance window

How long do change requests take to be completed?Per organization, user, type, step

Which transports belong to which change request and vice versa?

What is the current transport status (in which system)?

How many change requests were rejected?Per organization, user, type, by whom and why

How many corrections were withdrawn?Per organization, user, type, by whom and why

© SAP AG E2E200 7-418

© SAP AG 2007

Change Request Management Reporting: Access

Transaction /TMWFLOW/REPORTING (cross-solution reporting)

There are three points of access to Change Request Management Reporting: • Solution specific reporting: transaction DSWP: choose a specific solution Operations

Solution Reporting Change Management execute Change Management Reporting • Cross Solution reporting : transaction SOLAR_EVAL: Analysis Solution Change

Management

© SAP AG E2E200 7-419

© SAP AG 2007

Change Request Management Reporting: Status of Data

Status of Data field displays the date and time when the last data collector run took place. If, for any reason, the data collector could not collect data about a particular system (system downtime, for example), this system is displayed in the Differing Systems field. This field only appears if there are any inconsistencies. By clicking the icon next to the field, you can perform an online update of the system data (may take some time). The Differing Systems field then disappears.

© SAP AG E2E200 7-420

© SAP AG 2007

Change Request Management Reporting: Additional Information

Many more combinations of selection criteria are possible.

You can narrow down a query by returning to the selection screenand entering more information.

If the result list does not provide enough detail, you can always return to the selection screen to select a different view (Result Listgroup box -> Display field)

The Header view displays the least amount of detail; the Header, Project, Task List, and Transports view, for example, displays more details.

© SAP AG E2E200 7-421

© SAP AG 2007

Exercise

Exercise

© SAP AG E2E200 7-422

© SAP AG 2007

Appendix

PossibilitiesExamples

© SAP AG E2E200 7-423

© SAP AG 2007

Selecting List of Events

Results lists can be configured according to the entries in the following fields:

Grid fields:Header, Header, Project, and Task ListHeader, Project, Task List, and Transport RequestsHeader, Project, Task List, Transport Request, and Transport ObjectsSAP Notes and Support PackagesSupport Packages and Systems

(plus any combination these choices)

Layout: Any custom-defined layout

Hits: Maximum number of hits for the result list (Default is 100 hits)

© SAP AG E2E200 7-424

© SAP AG 2007

Selecting Transaction Data

Transaction data includes aspects of the cycle transaction, change request, and all change transactions.

Transaction data fields:Document identifier (number, date, transaction type, short text)External reference numberCreate and change dates User status and system status

OrgUnits:Business partner number and functionReference object (such as IBase or product)

Questions:What is the status of normal and urgent corrections of a project cycle that

have to be switched from the Development with Release to the To Be Tested phase?

© SAP AG E2E200 7-425

© SAP AG 2007

Selecting Project Header Data

Project header data groups combine project administration data and task list data.

Project header fields of project administration:Project Header (ID, Type, Create, End Date)Logical ComponentTransport TrackIMG and CTS Project

Task list data:All task lists and cycle task listTask list status and dates

Questions:Which change requests and change transactions exist, with which status,

with how many transport requests, and which objects for a selected project?

© SAP AG E2E200 7-426

© SAP AG 2007

Selecting System Data and Maintenance Data

Systems with components and maintenance versions can be selected:

System data:Log. System, System Role, Component Type, Component Version

Maintenance data:Support Packages SAP Notes and Note Corrections

Questions:Which component versions are available and in which systems?Which Support Packages or SAP Notes have been implemented, in which systems, and by whom?

© SAP AG E2E200 7-427

© SAP AG 2007

Selecting Transport Requests and Objects

Transport Requests with Tasks and Transport Objects Transport Requests and Transport Tasks:

Transport Requests (Name, Type, Category, User, Change Date)Status

Transport Objects:Object NamePackage Name View NameTable Name Table Key

Questions:Which objects exist, in which transport requests, with which status and, which project are they assigned to?Which systems are affected?Does a change request exist and if so, which status does it have?

© SAP AG E2E200 7-428

© SAP AG 2007

Change Request Management Reporting: Selection Example

In Syst. Status group box select In Process

Transaction Type field -> F4 to select relevant types (SDHF, for example)

Display all change transactions (urgent corrections, for example) that are being processed in the current system

© SAP AG E2E200 7-429

© SAP AG 2007

Change Request Management Reporting: Results Example

To navigate to change transaction (here: urgent correction) double-click relevant entry in column Transaction ID

Results of previous queryHeader data about the selected transaction type is displayed

© SAP AG E2E200 7-430

© SAP AG 2007


In Result List group box, select Header, Project, Task

List, and Transports

In Document Number field, enter the number

Important: Always choose Reset Selection Fields before starting a new query

Display all transport requests belonging to a change request (orurgent correction, maintenance, and so on)

© SAP AG E2E200 7-431

© SAP AG 2007


Columns highlighted

in color: You can

navigate to relevant

transaction, project, and

so on by double-clicking relevant

entry

Results of previous query:Header, project, task list, and transport data about the selected transaction are displayed

© SAP AG E2E200 7-432

© SAP AG 2007


Display which transactions a transport request belongs to.

© SAP AG E2E200 7-433

© SAP AG 2007


Results of previous query:Transactions that belong to the selected transport request are displayed.

© SAP AG E2E200 7-434

© SAP AG 2007


Use F4 to select partner number of a change manager.

Select transaction type.

Display change requests that were created by a particular change manager.

© SAP AG E2E200 7-435

© SAP AG 2007


Note: To display additional data on results screen (project or transport data, for example), return to selection screen and select different view in Result List group box

Results of previous query:Change requests created by the selected change manager are displayed.

© SAP AG E2E200 7-436

© SAP AG 2007


Use F4 to select Installed Base Component

Display all transactions for a particular production system (IBase component).

© SAP AG E2E200 7-437

© SAP AG 2007



Results of previous query:Transactions are displayed for the selected IBase component.

© SAP AG E2E200 7-438

© SAP AG 2007


Additional selection criteria can be entered (view name, and so on)

Use F4 to select Customizing Objects

Display which transactions have transported a particular Customizing object.

© SAP AG E2E200 7-439

© SAP AG 2007



Results of previous query:Transactions that have transported the Customizing object T005X are displayed.

© SAP AG E2E200 7-440

© SAP AG 2007


Display all transactions whose maintenance project status is completed.

© SAP AG E2E200 7-441

© SAP AG 2007



Results of previous query:Transactions whose maintenance project status is completedare displayed.

© SAP AG E2E200 7-442

© SAP AG 2007

Change Request Management Reporting: Selection Example for a Specific Solution

Use F4 to select a solution. Alternatively, select a solution in transaction DSWP and execute the Change Request Management report there. The solution is then included automatically in the Solution field of Change Management Reporting.

Display all change requests created for a particular solution (including project data).

© SAP AG E2E200 7-443

© SAP AG 2007



Retrofit

SAP Change Manager




© SAP AG E2E200 7-444

© SAP AG 2007

Change Manager: Change Tracking I

The Change Tracking function of Change Request Management allows you to track everything relating to changes within the context of a Solution Manager project, or an IMG project. It is possible to track all transport requests from the system where they are created, to the systems into which they are imported. Within the project context, all transport requests that belong to a particular project can be tracked across all the systems in the project landscape.

Project analysis: track all changes for one Solution Manager project or for one IMG project System analysis: compare change requests within systems, differences in the number of

change requests, and differences in the sequence in which requests are exported and imported Request analysis: track change requests, starting with the system where the request was

created, to all systems into which the transport is imported Start analysis: Transaction /TMWFLOW/CMSCONF Choose Tracking

© SAP AG E2E200 7-445

© SAP AG 2007

Change Manager: Change Tracking II

Scheduling analysis: analyze one transport track in a maintenance cycle, or analyze one maintenance cycle (including all transport requests)

There are different ways to start the analysis: • Transaction /TMWFLOW/CMSCONF ( Choose Tracking ( Scheduling Analyses tab page

(see slide above) • Transaction /TMWFLOW/MAINTINST ( Scheduling Monitoring tab page

© SAP AG E2E200 7-446

The scheduling tool (transaction /TMWFLOW/MAINTINST) performs the following activities: • Processes maintenance cycles for performing your development and maintenance tasks (for

regular maintenance) • Processes implementation projects • Processes template projects • Processes upgrade projects • Displays and changes the status of maintenance cycles, and implementation, template, and

upgrade projects • Distributes software within maintenance cycles • Analyzes maintenance cycles, urgent corrections, and implementation, template and

upgrade projects

© SAP AG 2007

Change Manager: Scheduling Tool

© SAP AG E2E200 7-447

Task-lists are based on project landscape role types: • Source System • Target System • Production System • Single System • Post-Processing System

When a project landscape changes, the systems have to be deleted/inserted correctly by an administrator.

Phases can be shifted from within the cycle task-list (as well as the cycle transaction). Cycle task-lists can be activated, locked, and completed. Track structures can be locked against usage from Normal Corrections, test messages, and

administration messages.

© SAP AG 2007

Change Manager: Task-List

© SAP AG E2E200 7-448

Scheduling and monitoring batch processing: • Daily imports • Parallel imports into multiple systems (ECC, CRM, BW, …) • Monitor task logs

Additional administrative tasks: • Insert additional tasks • Add notes and documents

© SAP AG 2007

Change Manager: Task List II

© SAP AG E2E200 7-449

Monitor tasks with detail log information

© SAP AG 2007

Change Manager: Task List III

© SAP AG E2E200 7-450

© SAP AG 2007



Retrofit

SAP Change Manager




© SAP AG E2E200 7-451

The locking of objects within an urgent correction, prohibits an urgent correction bypassing another with the same object, but a newer object version.

© SAP AG 2007

Project Buffer Project Buffer

Downgrade Risk with Urgent Corrections

DEV QAS PRD

Legend:

Urgent Corrections

1

2

3

4

31

© SAP AG E2E200 7-452

Normal Corrections or project transports that share the same production system, but have different life cycles can include different versions of the same objects.

Depending on the life cycle of parallel projects and on object conflicts, objects might be downgraded.

© SAP AG 2007

Project Buffer Project Buffer

Downgrade Risk with Normal Corrections

DEV QAS PRD

Legend:

Project1Project2Project3

© SAP AG E2E200 7-453

© SAP AG 2007

Cross-System Object Lock: Architecture 4.0



…


LockProjects


…

The Cross-System Lock allows locking objects from the change up to the import into production.

The Cross System Lock allows to lock objects that share the same productive system (ending system).

Objects can be locked between projects and urgent corrections within a maintenance project. Locks are performed on LIMU level for Workbench Objects and for Records for

Customizing objects.

© SAP AG E2E200 7-454

© SAP AG 2007

Cross-System Lock


NC(O1) – P2 – SYS1 failedUC(O2) – P1 – SYS1 failed NC(O3) – P2 – SYS1 failed UC(O2) – P2 – SYS2 failed

NC(O3) – P2UC(O2) – P2


LockProjects

NC(O1) – P1NC(O1) - P2UC(O2) – P1UC(O2) – P1NC(O3) – P2

The cross-system lock can be activated by the report /TMWFLOW/CONFIG_SERVICES There are four main different locking modes that can be configured (with SP8 for Solution

Manager 4.0 some new scenarios available. For more information see SAP Note 981729): • Cross-project and client-specific

- Urgent corrections cannot interfere – Error - All other changes are recognized – Warning

• Cross-project and cross-client - Urgent corrections cannot interfere, but only regarding cross-client Customizing,

ABAP, and DDIC – Error - All other changes are recognized – Warning

• Project-specific and client-specific - Urgent corrections cannot interfere - only for Customizing but not ABAP and DDIC

data – Error - All other corrections regarding Customizing between projects are recognized, ABAP

and DDIC changes are only recognized within a project – Warning • Project-specific and cross-client

- Urgent corrections cannot interfere regarding cross-client Customizing, ABAP and DDIC within a project context – Error

© SAP AG E2E200 7-455

- Other changes are recognized – Warning

© SAP AG E2E200 7-456

© SAP AG 2007



Retrofit

SAP Change Manager




© SAP AG E2E200 7-457

© SAP AG 2007


Critical objects are approved at the time of export.Critical objects are defined as:

ModificationsWorkbench objects in transport piece list formatCustomizing objects in transport piece list format

Critical object check is activated for each logical system:R3TR objectsLIMU objectsLogical objects for Customizing viewsTable entries for Customizing tables

Modification approval is activated once in SAP Solution Manager:Activate for each logical system

For general information about Critical Objects , refer to unit Transport Strategies, Lesson 5 The benefits of this procedure compared to the TMS check for critical transport objects are: • Customizing entries can also be marked as critical. • The check is performed at the time of the export from the development system. This gives

the organization many options on how to deal with that critical object. If a critical object is only detected at the time of the import, it is often difficult to postpone a scheduled Go-Live.

© SAP AG E2E200 7-458

© SAP AG 2007

Critical Object Definition

For the definition of critical objects use the transaction /TMWFLOW/CMSCONF select the critical object tab page

The check can be activated on a system-level and a client-specific level.

© SAP AG E2E200 7-459

© SAP AG 2007

Critical Object Approval

When a critical object is contained in a transport of the change transaction, no export is possible unless the change manager approves the critical object.

In the Schedule Manager application log, you see the following information: • Transport object checks are activated. • Request <request number> contains critical objects!

© SAP AG E2E200 7-460

© SAP AG 2007



Retrofit

SAP Change Manager




© SAP AG E2E200 7-461

© SAP AG 2007

Review: Phased System Landscape


QAS

Project Landscape

DEV TST

Ret

rofit

PRDCON

Phased based landscapes presuppose a Retrofit process This process will be supported in the future by Change Request Management (The Retrofit

process will come in 2007)

© SAP AG E2E200 7-462

© SAP AG 2007

Outlook: Retrofit Process

A retrofit system must exist in the solution manager maintenance project (role type: post processing system). It should be a development system of an other project, for example, an implementation project.

The Task-List of the maintenance project will have two new tasks: • In the Section General Task Assign post processing system to development system • In the Track Section Post processing systems Retrofit Systems Start Retrofit

After the start of the Retrofit Task transport, requests from the maintenance project, for which a retrofit is to take place can be selected.

For the execution of the Retrofit, a transport request must already exit in the retrofit system. The Retrofit process is based on the following tools: • Correction Workbench (SCWB) for Workbench Objects • Customizing Synchronization (Customizing Scout) for Customizing Objects

© SAP AG E2E200 7-463

© SAP AG 2007








Lesson 6: Tools


© SAP AG E2E200 7-464

© SAP AG 2007

Best Practices

Change Request Management workflows are based on best practices of how to manage short term changes, maintenance projects and new implementations.

Urgent Corrections for immediate changeNormal Corrections for midterm and long-term changesMaintenance projects for housekeeping activitiesImplementation projects for new implementations

© SAP AG E2E200 7-465

© SAP AG 2007




Review Best Practice for Transport Management

Use Case: System Landscape Approach

Use Case: Implementation Complexity

© SAP AG E2E200 7-466

© SAP AG 2007

Best Practices: Usage of Projects

Development Test Production

Implementation Project Market CampaignComplaint Management

…Maintenance Project ERP

… Maintenance Cycles


… Urgent Corrections

Rollout Brazil

Advantages: • Comprehensive customizing and development activities are grouped together • Basis for Release Management

© SAP AG E2E200 7-467

© SAP AG 2007

Best Practices: Phase Switching

NormalCorrections

Project PhasesDevelopment

(w/o or w/ release) Test Go-LiveEmergency Correction

No export No export No export

…



cProject

Synchronizing Synchronizing Synchronizing

Advantages: • All projects can choose one of the selected Go-Live dates. • All projects that Go-Live together also go into the test phase together. • Higher Stability in Production • Changes in production only at certain points

© SAP AG E2E200 7-468

© SAP AG 2007

Best Practices: Urgent Corrections are Preliminary Transports

Legend:

Maintenance ActivitiesUrgent CorrectionConsolidated Transport

Transport buffer Transport buffer

DEV QAS PRD

Advantage: • Consolidated Transports guarantee consistent project import/deployment.

© SAP AG E2E200 7-469

© SAP AG 2007

Project buffer Project buffer

Best Practices: Usage of Test Transports

DEV QAS PRD

Legend:

Normal CorrectionsTest Transports (Transport of Copies)

Advantage: • The Project buffer of the PRD System only contains consolidated changes.

© SAP AG E2E200 7-470

© SAP AG 2007

Best Practice: Cross-System Object Lock


…Production System


…

Test System


LockProjects

Advantages: • Identify changes on the same objects in different projects • Minimize Risk of downgrades through different go-live dates of changes from different

projects

© SAP AG E2E200 7-471

© SAP AG 2007

Best Practices: Critical Object Approval

Advantage: • Identify changes on critical objects (Prerequisite: knowledge of this objects)

© SAP AG E2E200 7-472

© SAP AG 2007

Best Practices: Retrofit


QAS

Project Landscape

DEV TST

Ret

rofit

PRDCON

Advantages: • Tool based • Minimized Risk through integration in the maintenance project • Logging of the changes

© SAP AG E2E200 7-474

© SAP AG 2007

DEV QAS PRDPRE

Change Request Management with Pre-Production System (example)

Best Practice:

Cross System Lock Critical Object Approval Process Additional Recommendations: Allocation of systems to phases • Development phase: DEV and QAS (using test transport for unit tests) • Test phase: PRE • Go-Live: PRD

Synchronize Go-Live with set-up of Release Management process: • all projects which are part of the next Go-Live enter the pre-production system together. • All other projects have to stay in the development or unit test environment.

© SAP AG E2E200 7-475

© SAP AG 2007

Change Request Management with Phased System Landscape (example)


QAS

Project Landscape

DEV TST

Ret

rofit

PRDCON

This slide shows one of the possibilities of using a phased based system landscape with change request management.

Maintenance Project (MAINT): • Contains the systems CON, QAS and PRD

Implementation Project (IMPL): • Contains the systems DEV, TST, CON, QAS and PRD

Recommendations: • Use Retrofit to avoid Downgrade • Use Critical Object Approval Process • Use system object lock

Note: This is only an example and not the only possibilities.

© SAP AG E2E200 7-476

© SAP AG 2007

Phased System Landscape: Phase Development


CON QAS

Project Landscape

DEV TST

Ret

rofit

PRD

The Implementation Project (IMPL) is in the Phase Development • The Systems CON, QAS and PRD are only virtual systems in the transport management

system for this landscape. • Unit test in system TST is based on test transports

All changes from the maintenance project (MAINT) must be taken over with a retrofit process into the project landscape.

© SAP AG E2E200 7-477

© SAP AG 2007

Phased System Landscape: Phase Test


CON

Project Landscape

DEV TST

Ret

rofit

PRD

QAS

In Phase Switch activities, some aspects need to be synchronized: • Switch the maintenance project (MAINT) to Go-Live (no further usage until next phase) • Set up new maintenance project (MAINT_URGENT) with transaction type SDMM (only

urgent corrections are possible, for more information see SAP Note 952803 ) for CON and PRD

• Set up retrofit process for the MAINT_UPG project • Copy PRD to QAS • Replace in the IMPL project the virtual QAS with the real QAS system

Phase Test: • In the IMPL project, all Normal Corrections are consolidated and imported into the QAS

System • Error handling with Test Messages

© SAP AG E2E200 7-478

© SAP AG 2007

Phased System Landscape: Phase Go-Live

CON

Project Landscape

DEV TST

Ret

rofit

PRD

QAS

Cut-Over


Phase Switch activities: • Transport the project buffer into the CON and PRD system. • The IMPL project will be set to Go-Live and then to close.

© SAP AG E2E200 7-479

© SAP AG 2007

Phased System Landscape: Next Cycle


QAS

Project Landscape

DEV TST

Ret

rofit

PRDCON

Phase Switch activities: • Switch the maintenance project (MAINT_URGENT) to Go-Live (no new urgent

corrections are possible). • Copy PRD to QAS. • Set the maintenance project (MAINT) to development with release. New changes are

possible. • Integrate the QAS system in the Maintenance landscape.

© SAP AG E2E200 7-481

© SAP AG 2007


Transport Management Approach

CycleTransaction

DEV

QAS

PRD


Controlled transportsCha

nge

Req

uest

Man

agem

ent

IT Operator

Project Cycle

Cycle Task-List

This scenario has the lowest complexity: • Usage of the task-list instead of TMS to import transports • Usage of the task-list instead of Workbench Organizer to create transport requests

Advantages: • projects and phase switching make release management possible • Improved tracking of transports with the Change Manager

© SAP AG E2E200 7-482

© SAP AG 2007


Extension: Change Document

Developer

Tester

DEV

IT Operator

QAS

PRD



Cha

nge

Req

uest

Man

agem

ent

ChangeDocument Task-

List

Project Cycle

This scenario is the entry in the CRM based transaction. In addition to the task-list functionality, you can use change documents to manage: • Only urgent corrections • Urgent and Normal Corrections

Advantages: • Comprehensible documentation of implemented changes and their ramifications • Tracking and audit ability • Consistent handling of urgent corrections

© SAP AG E2E200 7-483

© SAP AG 2007


Extension: Approval Process

Change Request

Requester

ChangeManager

DEV

QAS

PRD

Cha

nge

Req

uest

Man

agem

ent


List

Project Cycle

Developer

Tester

IT Operator



This is the complete Change Request Management Scenario. Advantages: • All best practices available • Comprehensible documentation of planned and implemented changes and their

ramifications • Improved efficiency of change management projects • Minimizes business disruptions • Tracking and audit ability

© SAP AG E2E200 7-484

© SAP AG 2007


Extension: Service Desk

Change Request

Service Message

PRD


Serv

ice

Des

kC

hang

e R

eque

st M

anag

emen

t


List

Feedback

Project Cycle

Requester

ChangeManagerDeveloper

Tester

IT Operator

DEV

QAS



This Extension bridges the gap between the incident / problem management process and the change / release management process.

© SAP AG E2E200 7-485

© SAP AG 2007

Unit Summary

You should now be able to:Understand important steps in the approval of a change requests

Know how change requests can be handled in SAP Solution Manager

Describe SAP’s best practices in transport management which are implemented in the SAP Solution Manager

© SAP AG E2E200 7-487

Exercises

Unit: Change Request Management Lesson: Change Requests

At the end of this exercise you will be able to: • Create a change request and thereby create a change document in the

SAP Solution Manager • Approve a change request and thereby create a follow up change

document

In this exercise you will go through the process where you act as a requester that creates a change request and as a change manager who approves the change request and generates by this activity a change document.

Prerequisites: A maintenance project has been generated (system demo). 7-1 Create a change request. Describe your requirements.

In this part you are acting as requestor 7-1-1 Log on to the SAP Solution Manager system and go to transaction

CRMD_ORDER. 7-1-2 Setup the buttons to create a Support Message (SLFN), Change Request

(SDCR) and Normal Correction (SDMJ) 7-1-3 Create a change request 7-1-4 Maintain description and partner functions. 7-1-5 Search for the production system that you want to make the change for.

Search in IBase “1” for that. 7-1-6 Maintain a change description 7-1-7 Save the change request and go back 7-1-8 Write down the transaction number after saving:

_______________________________________

© SAP AG E2E200 7-488

7-2 Find the change request. Take the change request into process.

In this part you are acting as a change manager 7-2-1 Find the Change Request via selection.

Go to the transaction monitor (transaction CRM_DNO_MONITOR) 7-2-2 Enter selection criteria to get your change request. 7-2-3 On the result list you should find the change request that you just created.

Double-click on the line to navigate into the change request 7-2-4 Go into change mode. 7-2-5 Classify the change request as a normal correction.

Saving should make the red error sign in the upper right corner disappear. After classifying the change request the red light is gone and processing can continue. Saving should make the red error sign in the upper right corner disappear.

7-2-6 Approve the change request and save the document. 7-2-7 Write down the number of the change document. Choose document flow

to access the number. _____________________________________________________________ _____________________________________________________________ Go back to SAP Easy Access menu.

© SAP AG E2E200 7-489

Exercises

Unit: Change Request Management Lesson: Maintenance Activities

At the end of this exercise you will be able to: • Process a change document in the SAP Solution Manager. Implement

the necessary corrections.

In this exercise you will go through the development process during an urgent correction. The change nanager has approved the change request and by this activity a change document was generated. The change document then passes through the development phase.

7-3 Find the change document. Take the change document in development. In this part

you are acting as a Developer. 7-3-1 Log on to the SAP Solution Manager system. Find your change document

(normal correction) via selection in the transaction monitor. 7-3-2 Open your change document. 7-3-3 Go into change mode. 7-3-4 Verify that the IBase component equals the IBase component of the

production system and change it manually if necessary. The IBase component is used to calculate the right maintenance system. Therefore, it is crucial that you use the right iBase component here. Write the IBase component down. _____________________________________________________________ _____________________________________________________________

7-3-5 Click on button Actions and choose Set to ‘In Development’. Save the document

7-3-6 Click on button Actions and choose Create Transport Request Save the document Check in the pop-up if your user is request owner and assigned to the tasks. Correct if necessary and confirm.

7-3-7 Click on button Actions and choose Logon to System to log on to the development system via a trusted RFC connection.

© SAP AG E2E200 7-490

7-3-8 Call transaction SM30 to maintain table T009T. 7-3-9 Search for the entry of your user and change the description 7-3-10 Save your entry. When prompted for a transport request, choose your own

customizing task via the button Own Requests.

© SAP AG E2E200 7-491

7-3-11 After saving your entry go to transaction SE09 in the development system. Release your customizing task that refers to your change document number.

7-3-12 To navigate back to the change document, choose ‘Back’ twice, and then ‘Exit’. You are now back in the Change Document.

7-3-13 Click on the button Actions and choose Complete Development. Choose Save.

7-3-14 Leave the document and the monitor list.

© SAP AG E2E200 7-492

Exercises

Unit: Change Request Management Lesson: Tools

At the end of this exercise you will be able to: • Run different selections in the area of the Change Request

Management

In this exercise you will go through the reporting part of Change Request Management You will learn how to select on project, transaction, transport order, and object level.

7-4 Select to transport level by using a Service Order.

7-4-1 Log on to the SAP Solution Manager system and find the change management reporting.

7-4-2 In the result list screen area choose D Header, Project, Task List, and Transports via the F4 help button.

7-4-3 Open the transaction data screen area 7-4-4 In the field Document Number fill in the number of your change document

you wrote down in Exercise “Change Requests” 7-4-5 Execute your selection. 7-4-6 Check your results and find the transport request

Please write down the transport request:

7-5 Select to object level by using a transport order. 7-5-1 Log on to the SAP Solution Manager system and find the change

management reporting. 7-5-2 In the result list screen area choose E Header, Project, Task List,

Transports, and Objects via the F4 help button. 7-5-3 Open the transport request screen area. 7-5-4 In the field Request/Task fill in the number of the transport request you

just wrote down in 1-1-6. 7-5-5 Execute your selection. 7-5-6 Check your results and find the object.

Write down the object:

© SAP AG E2E200 7-493

7-6 Select to transport level by using an object. 7-6-1 Log on to the SAP Solution Manager system and find the change

management reporting. 7-6-2 In the result list screen area choose E Header, Project, Task List,

Transports, and Objects via the F4 help button. 7-6-3 Open the transport objects screen area. 7-6-4 In the field Table Name enter “T009T” and in the field Table Keys enter

your object from 1-2-6. 7-6-5 Execute your selection. 7-6-6 Check your results.

© SAP AG E2E200 7-494

Solutions

Unit: Change Request Management Lesson: Change Requests

7-1 Create a Change Request. Describe your requirements. In this part you are acting as

Requestor 7-1-1 Log on to the SAP Solution Manager system. Enter the transaction code

“crmD_ORder” into the command field and choose Enter. 7-1-2 Press the button Settings (Ctrl+Shift+F8). In the tab Specific enter the

transaction types SLFN, SDCR and SDMJ as pushbuttons. 7-1-3 You are on the order processing screen now. Create a change request

Press Button , or navigate via menu Business Transaction -> Create -> Service Process -> Change Request

7-1-4 Maintain Description and Partner functions. Write a short description for the change and search for your BP in the partner functions Requester and Change Manager. Use Partner function “21” as Sold-to-Party.

7-1-5 Search for the production System that you want to make the change for. Press the F4 Help for the field Component. In the pop-up insert Installed Base “1” and confirm. Select component “94 Production Simulation”

7-1-6 Maintain a change description Go to the text maintenance box and select Text type “Description of change”. Write down your own description.

7-1-7 Save the Change request and go back The red light in the upper right corner indicates that the change request contains errors. Just ignore that, you will be able to save anyway. In this case the red light is triggered by the fact that the change request has not been classified according to the standard scenarios, yet.

© SAP AG E2E200 7-495

7-2 Find the change request. Take the change request into process. In this part you are acting as a change manager 7-2-1 Find the Change Request via selection.

Enter the transaction code “crm_DNO_MOnitor” into the command field and choose Enter.

7-2-2 Enter selection criteria to get your change requests. In the list selection check Mine in the business partner section and enter “SDCR” as transaction type in the service process section Choose Execute.

7-2-3 On the following monitor list, you should find the change request that you

just created. Double-click on the line to navigate into the change request.

7-2-4 Go into change mode: 7-2-5 Classify the change request as a normal correction.

Open the F4 help at the field Subject. There you can choose Normal Correction (Maintenance). Save.

7-2-6 Approve the change request. Choose button Actions and then Authorize Change Request.

Save the document. The change document is being generated. In general, operational activities like triggering the creation of a change document are always linked to a certain status of the current document. This ensures consistency between the administrational view and the technical execution.

© SAP AG E2E200 7-496

When a pop-up appears that asks you for a task list/maintenance cycle please choose the maintenance cycle of your group from Exercise 1.

© SAP AG E2E200 7-497

7-2-7 Write down the change document number. Choose document flow to access the number. _____________________________________________________________

• Leave the Change Request via the ‘Back’ arrow (F3) in the user interface.

• Leave the monitor list via the ‘Back’ arrow (F3) in the user interface.

© SAP AG E2E200 7-499

Solutions

Unit: Change Request Management Lesson: Maintenance Activities

7-3 Find the Change Document. Take the Change Document in development. In this part you are acting as a Developer. 7-3-1 Logon to the SAP Solution Manager system. Find the change document

(urgent correction) via selection. Type the transaction code “crm_DNO_MOnitor” into the command field and choose Enter. Enter selection criteria to get your change requests. In the List selection check “Mine” in the Business Partner section and enter “SDMJ” as transaction type in the Service Process section Execute

7-3-2 On the following monitor list, you should find the change document that you created in the last exercise. Double-click on the line to navigate into the change document (Fast Entry view).

7-3-3 Go into change mode. 7-3-4 Verify that the Ibase component equals the Ibase component of the

production system and change it manually if necessary. The Ibase component is used to calculate the right maintenance system. Therefore, it is crucial that you use the right Ibase component here. Write the Ibase component down.

7-3-5 Click on button Actions and choose Set to ‘In Development’. Save the document

7-3-6 Click on button Actions and choose Create Transport Request Save the document Check in the pop-up if your user is request owner and assigned to the tasks. Correct if necessary and confirm.

7-3-7 Click on the button Actions and choose Logon to System to logon to the development system via a trusted RFC connection.

7-3-8 Call transaction SM30. In the field Table/View enter “T009T”. Choose

7-3-9 Search for the entry of your user and change the description.

© SAP AG E2E200 7-500

7-3-10 Save your entry. When prompted for a transport request, choose your own customizing task via the button Own Requests Your customizing transport contains the number of your change document in its description. Write down the transport request number. _____________________________________________________________

7-3-11 After saving your entry, go to transaction SE09 in the development

system. Choose . Choose your customizing task that refers to your change document number and release it: . You must not release the transport request as this will be done by the SAP Solution Manager in the background. Furthermore, you are not allowed to release the transport request because the CTS status switches do not authorize you to do so.

7-3-12 To navigate back into the change document, choose ‘Back’ (F3) twice, and then ‘Exit’. You are now back in the Change Document.

7-3-13 Click on the button Actions and choose Complete Development. Choose Save.

7-3-14 Leave the document and the monitor list.

© SAP AG E2E200 7-501

Solutions

Unit: Change Request Management Lesson: Tools

7-4 Select to transport level by using a service order.

7-4-1 Log on to the SAP Solution Manager system and find the change management reporting: Choose SAP menu Tools SAP Solution Manager SOLAR_EVAL – Project Analysis or type the transaction code “SOLAR_EVAL” into the command field and choose Enter. You are in the solution manager analysis now, here choose Solution Change Management. You can also navigate directly to the change management reporting screen by using the transaction code “/n/tmwflow/reporting” in the command field and choosing Enter.

7-4-2 In the result list screen area please choose D Header, Project, Task List, and Transports via the F4 help button.

7-4-3 Open the transaction data screen area by clicking the button. 7-4-4 In the field Document Number fill in the number of your change document

you wrote down in Exercise “Change Requests” 7-4-5 Execute your selection

Press button or choose F8. 7-4-6 Check your results and find the transport request.

Please write down the transport request:

7-5 Select to object level by using a transport order. 7-5-1 Log on to the SAP Solution Manager system and find the change

management reporting. Choose SAP menu Tools SAP Solution Manager SOLAR_EVAL - Project Analysis or type the transaction code “SOLAR_EVAL” into the command field and choose Enter. You are in the solution manager analysis now, here choose: Solution Change Management You can also navigate directly to the change management reporting screen by using the transaction “code /n/tmwflow/reporting” in the command field and choosing Enter.

© SAP AG E2E200 7-502

7-5-2 In the result list screen area choose E Header, Project, Task List, Transports, and Objects via the F4 help button.

7-5-3 Open the transport request screen area by clicking the button. 7-5-4 In the field Request/Task fill in the number of the transport request you

just wrote down in 1-1-6. 7-5-5 Execute your selection.

Press button or choose F8. 7-5-6 Check your results and find the object.

Please write down the object: 7-6 Select to transport level by using an object.

7-6-1 Log on to the SAP Solution Manager system and find the change management reporting. Choose SAP menu Tools SAP Solution Manager SOLAR_EVAL – Project Analysis or type the transaction code “SOLAR_EVAL” into the command field and choose Enter. You are in the solution manager analysis now, here choose: Solution Change Management You can also navigate directly to the change management reporting screen by using the transaction code “/n/tmwflow/reporting” in the command field and choosing Enter.

7-6-2 In the Result List screen area choose E Header, Project, Task List, Transports, and Objects via the F4 help button.

7-6-3 Open the transport objects screen area by clicking the button. 7-6-4 In the field Table Name fill in “T009T” and in the field Table Keys fill in

your object from 1-2-6.

7-6-5 Execute your selection. Press button or choose F8.

7-6-6 Check your results.

© SAP AG E2E200 8-504

© SAP AG 2007

Contents:

SAP Maintenance Strategy

Types of Corrections

Support Package Stack Strategy

Support Package Content Analysis

Software Life-cycle Management Tools

Maintenance Optimizer

HotNews Inbox


© SAP AG E2E200 8-505

© SAP AG 2007

Maintenance Management: Unit Objectives


Know the SAP Maintenance Strategy

Describe all types of patches delivered by SAP

Explain the support package stack strategy

Execute side effect Reporting for a Support Package Queue

Estimate the impact of a support package import into a critical system

Use the software lifecycle management tools to implement patches and find information on current patch levels

Explain the additional benefit of the SAP Solution Manager in the maintenance process

© SAP AG E2E200 8-506

© SAP AG 2007

Maintenance Management Unit Overview Diagram


Lesson 3: Support Package Stack Strategy

Lesson 7: Maintenance Optimizer

Lesson 5: Support Package Content Analysis

Lesson 6: Applying Support Packages

Lesson 1: SAP Maintenance Strategy

Lesson 8: HotNews Inbox

Lesson 4: Side-Effect Reporting

Lesson 2: Types of Corrections

© SAP AG E2E200 8-507

© SAP AG 2007

2011 2012

Release and Maintenance Strategy mySAP ERP

2005 2006 2007 2008 2009 2010

mySAP ERP2004

SAP R/3 Enterprise

47x200

SAP R/3 4.6C

SAP R/3 3.1I – 4.6B

mySAP ERP2005

Dec Mar

Dec Mar

This strategy is also valid for all industry-specific add-on applications based on the releases above.

Mar

Mar

2013

Dec

Mar

Mainstr.Maint.

Ext. Maint. (+ 2%)*

Ext. Maintenance (+ 4%)*

Customer-SpecificMaintenance

Mainstream Maintenance Ext. Maint. (+ 2%)*



* Overall payment is SAP Standard Support / SAP Premium Support fee plus additional fee of 2% or 4% of the maintenance base per year.

SAP R/3 Enterprise

47x110Mainstream Maintenance Ext. Maint.

(+ 2%)*Ext. Maintenance

(+ 4%)*Customer-Specific

Maintenance

Ext. Maint. (+ 2%)*


Customer-SpecificMaintenanceMainstream Maintenance

Ext. Maint.(+ 4%)*


Jun

Oct Mar

Mainstream Maintenance Ext. Maint. (+ 2%)*


Ramp-Up

2014 2015 2016


Enh. Packages2005.32005.22005.1

The 5-1-2 maintenance strategy was introduced in 2004. It applies to releases based on SAP NetWeaver 2004 and higher.

The maintenance phases have the following durations: • Five (5) years of mainstream maintenance at the SAP Standard Support or SAP Premium

Support fee, depending on which support option the customer chooses • One (1) year of extended maintenance at an additional 2% fee • Two (2) years of extended maintenance at an additional 4% fee • Thereafter, the release enters customer-specific maintenance.

© SAP AG E2E200 8-508

© SAP AG 2007

Product Availability Matrix

View in Service Marketplace:All product versions are displayed with general availability date and end of maintenance date.

To continue, choose a product

version

To continue, choose a product

version

http://service.sap.com/pam

The Product Availability Matrix bundles technical and release planning information on SAP components for quick reference. You will find information on the availability of SAP component releases (product versions), maintenance end dates and upgrade paths, as well as technical release information (DB-platforms, JSE-platforms, operating systems, languages, countries etc.). A SAP component release is structured into instances. An instance is a bundle of technically dependent software component versions to be installed on one single logical system. The technical release information is displayed per instance. Example: The SAP component release SAP R/3 4.6C is structured into the instances R/3 Server, Frontend GUIs etc. The R/3 Server itself consists of the software component versions SAP APPL 4.6C, SAP HR 4.6C, SAP ABA 4.6C, SAP BASIS 4.6C and SAP Kernel 4.6C 32-BIT (or a newer downward compatible one).

© SAP AG E2E200 8-510

© SAP AG 2007

Types of Corrections

Support Package Stack

SAP Kernel Patch

Standard correction process

Java Single Patch (Fix)SAP Note Correction (ABAP)

Java Support Package

Java Support Package Patch

ABAP Support Package

Emergency correction process

JavaABAPCorrection Process

Standard correction process: • Support Package Stack:

− Description: The Support Package Stack is a list of ABAP and Java Support Packages for all software components (SC) included in SAP NetWeaver. It is used to bring each Software Component of SAP NetWeaver to a defined SP level.

• ABAP Support Package: − Description: ABAP Support Packages contain quality improvements for the SAP

system, or make necessary adjustments due to legal changes, for example. The objects affected are replaced in your system.

• Java Support Package: − Description: Java Support Packages are used to ship correction levels of Software

Components. They correspond to the ABAP Support Packages.

Emergency correction process: • SAP Note Correction (ABAP):

− Description: SAP Note Corrections contain single ABAP fixes. • Java Support Package Patch:

© SAP AG E2E200 8-511

− Description: A Java Support Package patch contains corrections for the Java Software Components. Java Support Package patches are normally created and released on demand. They correspond to a SAP Note that describes the same correction.

© SAP AG E2E200 8-512

• Java Single Patch: − Description: A full version of a single Development Component. Java single patches

correspond to a SAP Note that describes the corresponding prerequisites and dependencies.

© SAP AG E2E200 8-513

© SAP AG 2007




Java Corrections

ABAP Corrections


© SAP AG E2E200 8-514

© SAP AG 2007

SoftwareComponents

ReleaseP1 P2

S1 S2

Products

SupportPackage (in ABAP, not the complete SC is shipped - only the changed objects)

Component Model and Maintenance

Packages

O1

D4

O3

D7

D8D6

D5

D11

D10D9

NotesO2Objects

The SAP component model for ABAP objects is shown above: • Products are updated by installations and upgrades. • Software components are updated by Support Packages and Add-ons. • Single objects an be updated by SAP Notes.

© SAP AG E2E200 8-515

© SAP AG 2007

SAP Note in the Service Marketplace

SAP Notes: • Describe how to remove known errors in the SAP System. They include a description of

the following: − the symptoms of the error − the root cause of the error − the release and Support Package status for which they are valid

• They contain (depending on the type of error): − workarounds − descriptions of how to correct the source code (correction instructions) − links to Support Packages that correct the problem

• Correction instructions change single lines of coding. • SAP Notes with correction instructions are implemented with the Note Assistant in the

development system, and then forwarded by transports to production.

© SAP AG E2E200 8-516

© SAP AG 2007

Correction Instruction: Changing a Function Module

FUNCTION test_package_attributes.*"----------------------------------------------------------------------*"*“Local Interface:*" IMPORTING*" VALUE(IV_PATCH) LIKE PAT03-PATCH*" EXPORTING*" VALUE(ES_PAT03) LIKE PAT03 STRUCTURE PAT03*" TABLES*" T_PAT07 STRUCTURE PAT07*" T_PAT08 STRUCTURE PAT08*" EXCEPTIONS*" NOTHING_FOUND*"----------------------------------------------------------------------

SELECT * FROM pat03WHERE patch = iv_patch.

ENDSELECT.

IF sy-subrc <> 0.RAISE nothing_found.

ENDIF.

MOVE-CORRESPONDING pat03 TO es_pat03.

SELECT * FROM pat07 INTO TABLE t_pat07WHERE patch = iv_patch.


CALL SCREEN 0100 STARTING AT 14 2.

ENDFUNCTION.

FUNCTION test_package_attributes.*"----------------------------------------------------------------------*"*“Local Interface:*" IMPORTING*" VALUE(IV_PATCH) LIKE PAT03-PATCH*" EXPORTING*" VALUE(ES_PAT03) LIKE PAT03 STRUCTURE PAT03*" TABLES*" T_PAT07 STRUCTURE PAT07*" EXCEPTIONS*" NOTHING_FOUND*"----------------------------------------------------------------------

SELECT * FROM pat03 INTO es_pat03WHERE patch = iv_patch.

ENDSELECT.

IF sy-subrc <> 0.RAISE nothing_found.

ENDIF.


ENDFUNCTION.

Old version New version

Objects that can be changed with the Note Assistant: • New Objects can be created • CLAS: Global ABAP Classes (ABAP-OO) • INTF: Interfaces (ABAP-OO) • REPS: ABAP programs and includes • FUNC: Function modules with interface and all attributes • DYNP: Screens with all attributes • TYPD: Type Pools • WAPP: Business Server Pages • SMIM: MIME objects (only with small data volume) • IAMU, IARP, IASP, IATU: Internet transaction server • ENH*: Enhancement objects

Objects which are not supported: • Creating an entire function group • BSP applications • Deleting an object • Changes to tabular content (R3TR TABU)

© SAP AG E2E200 8-517

• Language dependent texts • DDIC objects

© SAP AG E2E200 8-518

© SAP AG 2007

Note Browser

The Note Browser gives you a list of all SAP notesSelect all notes with implementation status “Completely implemented”Transaction SNOTE GOTO SAP Note Browser

The Note Browser gives you a list of all SAP notes which are imported into an ABAP system Select all notes with implementation status “Completely implemented” Transaction SNOTE GOTO SAP Note Browser

© SAP AG E2E200 8-519

© SAP AG 2007

ABAP Support Packages

http://service.sap.com/swdc

ABAP Support Packages: • All note corrections within a certain time period are bundled into a support package. • A support package contains full objects, not just single lines of coding. • Support packages are delivered for each software component. • Support packages are incremental. That means that all support packages of a software

component must be implemented. • Support Packages contain all objects that were changed in a certain time period.

© SAP AG E2E200 8-520

© SAP AG 2007

System Status: Version Information of ABAP Systems

The version information of ABAP based systems can be reached via the Menu Bar: • System Status Button „Component information“

© SAP AG E2E200 8-521

© SAP AG 2007




Java Corrections

ABAP Corrections


© SAP AG E2E200 8-522

© SAP AG 2007

(Fix)

Component Model and Maintenance

SoftwareComponents

ReleaseP1 P2

S1 S2

Products

SupportPackage (in JAVA, the complete SC is Shippe. Packages are cumulative)

Packages

O1

D4

O3

D7

D8D6

D5

D11

D10D9

O2Objects

Software maintenance is organized into three tiers: Products are installed or undergo an upgrade to a new release. A release is a full delivery of

software components that provide new functions (and possibly user interfaces) or improvements. Installation and upgrade are not performed with CMS resources.

A Support Package (SP) is (unlike ABAP) a full delivery of one (or more) software component(s) and contains a number of fixes. The usual file format of an SP is the SCA format. Support Packages are implemented using the Java Support Package Manager Tool (JSPM). JSPM distinguishes between Systems that are under NWDI control and systems that are not under NWDI control.

Fixes are full deliveries of a development component that allow a quick error correction, before the complete SP is available. The usual file format is the SDA format. • Hint: SAP usually does not yet deliver fixes. The smallest unit of delivery of SAP

software is a Support Package.

Development Objects (DOs) • Stored as versioned files in the source repository (DTR) • Example: Web Dynpro view, table definition, Java source file

© SAP AG E2E200 8-523

Java-based Support Packages are cumulative. Update from a lower SP Stack to a higher SP Stack only requires the import of the appropriate target SP Stack

© SAP AG E2E200 8-524

© SAP AG 2007

Java Fixes

Software Component

Development Component 1




Fix

The smallest unit that can be delivered is the softwaredevelopment component, which is shipped in a softwaredevelopment archive (SDA)A fix corrects a single errorSDA-file fixes are used for preliminary correction in urgent cases or for releases prior to SAP NetWeaver 2004sPublished on demand as attachment in SAP notes or customermessagesOnly apply fixes with guidance from SAP’s support. Apply the next higher support package stack instead

Java Objects are grouped in Development Components. Development Components are grouped in Software Components. The smallest unit that can be delivered is a complete Development Component (Fixes). Fixes should only be applied in emergency situations and with guidance from SAP Support.

© SAP AG E2E200 8-525

© SAP AG 2007

Java Support Packages

SCA, SP20

SDA 1SP18

SDA 2SP20

SDA 3SP16

SDA 4SP17

SDA 5SP20

Java Support Packages:Include all corrections and updates in the period since the last support packageSupport packages are delivered for software components. They areshipped as software component archives (SCA) Software component archives contain several software developmentarchivesSupport packages are delivered at regular intervals as part of a supportpackage stack according to a scheduleJava support packages are cumulative. That means each supportpackage contains all of the predecessors

© SAP AG E2E200 8-526

© SAP AG 2007

Java Patches

SCA, SP20, Patch 1

SDA 1SP18

SDA 2SP20

SDA 3SP16

SDA 4SP17

SDA 5Fix

Java Patches (as of Netweaver 2004s):Like a regular support package, a patch contains a fullsoftware component and is delivered as software componentarchive (SCA).A patch contains the latest regular support package plus all fixes that were published since the release of the latestsupport package.It is published on demand.

© SAP AG E2E200 8-527

© SAP AG 2007

SAP Service Marketplace

Java Patches and Support Packages are published on the SAP Service Marketplace, quick link /swdc

Java Support Packages and Patches are delivered as full Software Component Archives. Support Packages have Patch Level 0. Patches have a higher Patch Level.

Patches are always created for the highest Support Package Level. They are also created for lower Support Package Levels, if required.

If you click on „Info“ of a patch, you see a list of notes which describe the individual corrections, which are solved with the patch. For support packages, there is a summary note which describes all corrections in the support package.

© SAP AG E2E200 8-528

© SAP AG 2007

SAP Notes

SAP Notes describe single bugs which are fixed in patches.

This note describes a problem which is solved by support packages or patches. One solution is to apply NW04s, SP11. Patches were also provided for the support package levels 09 and 10.

© SAP AG E2E200 8-529

© SAP AG 2007

Component Info: Version Information of Java Systems

Release 7.00 SP Level 10

Patch 1

http://<hostname>:<port>/sap/monitoring/ComponentInfo

The version information of a JAVA based system can be seen in the Component Information. http://<hostname>:<port>/sap/monitoring/ComponentInfo For each software component, the Version string shows Release, Support Package and

Patchlevel.

© SAP AG E2E200 8-531

© SAP AG 2007

R/3

Support Package Stacks (SP Stacks)

Appl.

ABA

Basis

Kernel

Appl.

ABA

Basis

Kernel

Appl.

ABA

Basis

Kernel

SAP releases sets of Support Packages per product and quarter – the SAP Support Package Stacks (SP Stacks)

Support Packages & patches of SP Stacks must be used in the given combination,other combinations only apply for exceptional cases

Higher quality and ensured compatibility of included Support Packages

Simplified download of included Support Packages from a one page summary

Accelerated application, lower cost of operations and system maintenance

APO

BW

tQ1 Q2 Q3 Q4

Support Package Stacks: • Contain the optimal combination of Support Package and patch statuses for the individual

components at the given time • Reduce the complexity of Support Package application • Increase quality and transparency • SP Stacks are already tested at SAP • SP Stacks are well known at SAP

SAP recommendation: Apply a Support Package Stack as a whole to update an SAP

system

© SAP AG E2E200 8-532

© SAP AG 2007

Support Package Stack Download

Service Marketplace quick link /sp-stacks

Selection of an application component implicitly includes underlying technology stack

– Example:XSS EP Java

In the first step, you have to select the source and target stack and the scenarios of SAP ERP 2005 that you are using.

Scenarios which are not used must not be patched.

© SAP AG E2E200 8-533

© SAP AG 2007

Selection of Platform

Operation SystemUnicode vs. non-UnicodeDatabase

In the next step you have to enter your technology platform (operating system, database, unicode, 32-Bit or 64-Bit).

© SAP AG E2E200 8-534

© SAP AG 2007

Save the Stack Definition XML File

Don’t forget to save the Stack Definition XML file!

Save the stack definition XML file. This file is used by the JSPM in order to define the correct import queue.

© SAP AG E2E200 8-535

© SAP AG 2007

SAPGUI and Kernel Version

Check minimum required SAPGUI version .

Check recommended kernel version.

When you import a support package stack, you must also check the minimum required SAPGUI version. It is not required to update the SAPGUI with every Support Package stack import, but the minimum requirements should be fulfilled.

If you are below the recommended SAPGUI version, but above the minimum required SAPGUI version, this might only prevent some features with minor impact from working correctly.

There is shown a minimum required and a recommended kernel version. When you import a support package stack you should also apply the recommended kernel version.

© SAP AG E2E200 8-536

© SAP AG 2007

SP Stack Schedule

Note: These dates may change

SAP Service Marketplace, Link /SP-Stacks: http://service.sap.com/sp-stacks

In the Service Marketplace, there is a support package stack calendar which shows the planned availablity of the support package stacks for the different products.

You can use this calendar to schedule your maintenance projects. Products which are new or still in the ramp-up phase have a high support package stack

frequency (e.g. monthly). Older and stable releases only deliver support package stacks twice a year.

© SAP AG E2E200 8-538

© SAP AG 2007

Side-Effects of Single Notes

In some cases, SAP Notes and Support Packages are dependent on each other. Resolving a particular issue with one SAP Note may cause new issues to arise in other areas or situations. To resolve these new issues, SAP publishes new SAP Notes that are related to the original SAP Note. Before implementing an SAP Note, you should check if it has any side-effects.

On the SAP Service Marketplace, quick link http://service.sap.com/notes, you can view any known side effects on the Side Effects tab of a single SAP Note. The upper table on this tab displays other SAP Notes that can be corrected using this SAP Note, whereas the lower table shows other SAP Notes that correct the side effects of this SAP Note.

© SAP AG E2E200 8-539

© SAP AG 2007

Side-Effect Report

776552

743543

...

SPy Note

------------------------

VersionSuppPackage

---------------

Version

-----

NoteSide-effect

--------

--------

SPx Note

7351027643223443

23423465546546456445646633535

22342423223

VersionSuppPackage

0012001000010003000500080001000100020004

Version

00030004

0002

NoteSide-effect

376552

343543

321254, ...

Queue Calculation:Side Effects that are solved within the same SP queue will be filtered automatically Individual calculationSide Effects that are solved within a foreign SP queue are not yet filtered automatically (future extension)Open topics of Side Effect reporting: see SAP Note 684859

Example

Side-Effects Reporting: Calculation for SP Queues

SAP Support Packages are collections of SAP Notes that provide software corrections. Since SAP Notes in subsequent Support Packages solve most of the side effects caused by a

Support Package, these notes must be excluded from the list of side effects. Only side effect notes, which are not contained in the import queue, need to be imported

separately after a support package import.

© SAP AG E2E200 8-540

© SAP AG 2007

Side Effects Reporting Tool in the SAP Service Marketplace

To allow easier detection of these interdependencies, a reporting tool is available on the SAP Service Marketplace. When importing a Support Package or SAP Note, you can check for known side effects and find relevant SAP Notes to treat these. Using the tool, you can proactively prevent problems that may occur as a result of applying Support Packages or SAP Notes, not only accelerating and improving the quality of issue resolution, but also reducing maintenance effort and costs.

© SAP AG E2E200 8-541

© SAP AG 2007

Number of Known Side-Effects over the Time

InternalTests

Release of SP Stack

DevelopmentClose

CustomerProjects

Side effectNotes

Side effectNotes

Most bugsare fixed

CustomerMessages

InternalMessages

Number of Known

Side Effects

The number of known side effects of a support package rises continuously after the time of the development close. Most side effects are known at the time a support package is released.

However, if you execute the side effect report several times, you might see more known side-effects if you execute the reporting at a later point in time.

© SAP AG E2E200 8-543

© SAP AG 2007




Custom Development Optimization Package

Analysis of SAP Notes in Support Packages





© SAP AG E2E200 8-544

© SAP AG 2007

Get List of Notes from SAP Service Marketplace

Click on title to get the list of

notes

http://service.sap.com/swdc

SAP Support Packages are collections of SAP Notes. You can see the available support packages in the Software Download Center of the SAP

Service Marketplace. If you click on the title of a support package, you get a list of SAP Notes which are contained

in it.

© SAP AG E2E200 8-546

© SAP AG 2007

Number of Notes per Software Component

In this example, an R/3 Enterprise system was patched fromSource Stack Level 18 to Target Stack Level 24. The number of notes per Software Component was as follows:

SAP_APPL 15.969SAP_BASIS 4.431SAP_ABA 2.034EA_APPL 1.704EA_IPPE 81Total 24.219

This slide shows the number of notes per component of a specific support package stack.

© SAP AG E2E200 8-547

© SAP AG 2007

Number of Notes per Application Component

The application components with most changes are:BC Basis 4286FI Financials 2297CA Cross Application 1711LO Logistics 1674MM Material Management 1667CO Controlling 1509PP Production Planning 1340SD Sales and Distribution 1329XX Others 1315LE Logistics Execution 1128

This slide shows the number of notes per application component.

© SAP AG E2E200 8-548

© SAP AG 2007

Number of Notes per Application Sub-Component

IdentifyRelevant

Components

FI-AP-AP Accounts Payable 602FI-GL-GL General Ledger 544XX-CSC-IN Country Spec. India 436AP-MD-BP Business Partner 405MM-PUR-GFPurchasing 377XX-CSC-BR Country Spec. Brazil 319FS-BP Fin.Serv. – Bus.Part. 304LE-SHP-DL Delivery Processing 287CO-PC-ACT Actual Costing 284FI-AA-AA Asset Accounting 280

Now the number of notes is displayed per application sub-component. This view makes it clear in which areas most changes took place. The customer can now select

components which are relevant for him. He can also see if there are components which have no changes at all.

© SAP AG E2E200 8-549

© SAP AG 2007

Analyze Shorttext of Notes

Delivery Processing is a critical application for this customer. Therefore, he checked the short texts of all notes in this component. Critical notes will be checked in more detail.

For the relevant components you can now quickly review the short text of the notes and decide if the individual note is relevant.

The relevant notes must then be read in detail.

© SAP AG E2E200 8-550

© SAP AG 2007

Notes by Category

K FAQ 12

N Exit added 91

P Performance 388

R Release planning information 7

T Correction of Legal functions 867

U Upgrade information 6

W Workaround for missing funct. 51

X External error 14

Y Help for error analysis 24

Grand Total 24.219

Each Note has a category. Most notes are in the category “Program Error”. Legal changes are most critical.

A Program error 21.621

B Consulting 89

C Customizing 83

D Advance development 240

E Special development 109

F Documentation error 87

G Translation error 215

H Legal change 294

I Installation information 21

Another approach is to select notes by category. About 90% of the notes are in category Program Error. These notes are rather uncritical regarding side effects.

Most critical are notes of type Legal change.

© SAP AG E2E200 8-551

© SAP AG 2007

Analyze Short text of Notes

Legal Changes are critical. Therefore, this customer checked all notes of this category. Critical notes will be checked in more detail.

For the legal changes you can now quickly review the short text of the notes and decide if the individual note is relevant.

The relevant notes must then be read in detail.

© SAP AG E2E200 8-553

© SAP AG 2007


RFCBasis 4.6C / WebAS 6.20 / 6.40 / 7.00

CDOP Control Center

Start-Up

Work-Shop

Clearing Analysis

Enabling base technologyGeneral functionality, „middleware“„Applications“

Customer in advance of upgrade

or reorganization project

Cer

tifie

d us

ers*

) in

CD

OP

proj

ects

Customer in upgrade

or change (support package or

transport import) project

*) certified users by attendance ofe-learnings

Del

iver

able

sR

ecei

vers

Upgrade / ChangeImpact Analysis

The Custom Development Optimization Package is part of the Solution Support Enablement Package (SEP). This is an Add-on to SAP Solution Manager.

With the Upgrade/Change Impact Analysis, you can find out about the technical impact of an SAP Upgrade or Support Package on your custom developments and estimate the amount of work required to adapt them.

© SAP AG E2E200 8-554

© SAP AG 2007

Upgrade/Change Impact Analysis

Upgrade/Change Impact Analysis:Identification of relevant customer workbench objectsDetermination of SAP objects used in custom codeQualified determination of changed SAP objects in upgrade or support packageIntersection between these two setsDisplay of workload (“hit objects“) for adaptation with supporting functionality

Control centerNavigation and control of CDOP tasks

When the comparison is finished, you can look at the analysis results and decide how to proceed with the listed objects. You have various options for viewing and filtering the data. You can set the processing status for each object you analyzed. You can even do extended syntax checks for custom objects and get where-used lists for SAP objects on the list. You can calculate total adjustment times for different sets of objects to get a clearer idea of the amount of work that is required in different areas.

© SAP AG E2E200 8-555

© SAP AG 2007

Upgrade / Change Impact Analysis - Systems

CDOP ControlCenter

ReferenceSystem

AnalyisSystem

Changed SAP Objects byUpgrade, SP, Transport

SAP ObjectsReferenced by

customer objects

Comparision

The Upgrade / Change Impact Analysis tool compares the SAP objects that were changed by an Upgrade / Support Package or transport with the objects that are referenced by Customer objects.

A reference system is needed in which the change was already applied.

© SAP AG E2E200 8-556

© SAP AG 2007

Upgrade / Change Impact Analysis - Steps

Find Used SAP Objects: • In this activity, a list of all the SAP objects that are used in custom developments in the

analysis system is prepared. The list can include either all objects in the customer namespace or only objects from the specified development classes (packages). The SAP objects found in this activity will be used as the basis for the next activity - Find Changed SAP Objects.

Find Changed SAP Objects. • In this activity, you find the intersection of the SAP objects used in the custom objects and

the changed SAP objects. This activity runs in the reference system. • For a support package application (transport request/ task), the program finds the

intersection by comparing the objects from the piece lists for the support package against the SAP objects used by customer-specific objects as specified in the preceding steps.

• For an upgrade, the program compares the objects in the list of changed SAP objects (as provided by SAP) against the SAP objects used by customer-specific objects as specified in the preceding steps.

Perform Remote Comparison: • In this activity, you compare the relevant objects in the reference system against their

counterparts in the analysis system with the aim of estimating the effort required to adjust these objects. Note that this activity, like all the others, is triggered from the control system

© SAP AG E2E200 8-557

and obtains the required information from the analysis system and the reference system through the RFC connections.

• A list of the objects with the updated comparison result is provided in step Display Results.

© SAP AG E2E200 8-558

Display Results: • In this activity, you get an overview of the analysis results and can decide how to proceed

with regard to the listed objects.

© SAP AG E2E200 8-559

© SAP AG 2007

Upgrade/Change Impact Analysis – Results

The following options are available: • Object view: You can display either all found objects or only the objects of one object type

(such as data elements or programs). You can also view all customer-specific objects which do not use any SAP object.

• Severity: Display only the objects of selected severity . • Processing status: Display only the objects of selected processing status. • Compressed view: In the compressed view, you can view all the attributes of custom

objects (such as object type, development class, adjustment time or severity of the impact) • Detail view: In the detail view, you can view all the SAP objects used by a given custom

object with their object types and severity. • Change mode: In the change mode, you can assign a status to each object, assign a

processor to each object, and send a notification to the processors.

© SAP AG E2E200 8-560

© SAP AG 2007

Solution Support Enablement Package (SEP)

Packaged Tools:BMC AppSight for Windows/.NetSAP Test Data Migration ServerCA Wily IntroscopeSAP Custom Development

Optimization PackageSAP Reverse Business EngineerSAP Best Practices for

Operations

The Solution Support Enablement Package provides a suite of proven tools that enable your IT support organization to deliver

best-in-class support for your SAP solution.

Find more information at http://service.sap.com/sep

In E2E Change Control, the following Solution Support Enablement Package tools are of special interest: • SAP Custom Development Optimization Package:

− Change Impact Analysis during testing and import of support packages or upgrades • SAP Client Migration Server:

− Customizing and repository compare of two systems (homogeneity of the system landscape)

• SAP Test Data Migration Server: − Set up test systems with current test data

© SAP AG E2E200 8-562

© SAP AG 2007

Three Steps to the New Support Package Stack

1 2 3

Apply ConfigureDownload

Download support package stacks from the SAP Service Marketplace. Import the support package stack with the Software Lifecycle Management tools. Perform the post-implementation configurations that are described in the Support Package

Stack Guide.

© SAP AG E2E200 8-564

© SAP AG 2007

Importing ABAP Support Packages – Steps during Uptime

Download and install the newest transport tools, tp and R3trans.

This can clearly be done during uptime

Import the latest SPAM update.This can be done during uptime

Upgrade the Add-Ons ST-PI and ST-A/PI with SAINT.These Add-ons deliver Early-watch functionality and can be imported during normal productive work.

Define one complete queue in SPAM and process until the end of the import module 'Import 1‘.

Use the downtime-minimized import modeOne Add-on Delta Upgrade in SAINT can also be included in the queue

© SAP AG E2E200 8-565

© SAP AG 2007

Importing ABAP Support Packages – Steps during Downtime

Process the SP queue import until the end of the import module ‘Import 2’.

Now, all SAP objects are imported

Do the following tasks in parallel:Continue with the 'Postprocessing' in SPAM till the endImport the customer transports Set GENERATION = FALSE

Exchange the kernel and restart the system.

Do the following tasks in parallel:Run SGEN (could also be done when the system is released for productive use) Perform functional tests

If everything is ok, release the system for productive use.

© SAP AG E2E200 8-566

© SAP AG 2007

Additional Recommendations

Start with a test import in order to generate the SPDD and SPAU list.

No more customer transports in phases Import 1 and Import 2Un-schedule automatic imports !

SPDD adjustment must be done in each system separately.

SPAU adjustment can be done by transport request.

Backups of database and Import-Buffer should be taken before the Downtime starts.

© SAP AG E2E200 8-567

© SAP AG 2007

Known Problems with Support Packages

For each release, there is a central note which contains known problems with Support Package imports.

Proactively read this note and follow the instructions. Often, split points are recommended. That means certain support packages should not be

applied together in one import queue. Proactively check the related notes mentioned in the central note, aslo.

© SAP AG E2E200 8-568

© SAP AG 2007

Downtime Minimized Method

Standard Process

Preparatory andTest steps

Import steps during productive

operation

Cleanup steps

Downtime-minimized Process

Preparatory andtest steps

Import stepsduring productive

operation

Import steps duringnon-productive

operation

Cleanup steps

Import steps duringnon-productive

operation

Standard process: Internal processing of the individual steps was reorganized and divided into four modules: Prepare and test module; Import 1 during productive operation; Import 2 during non-productive operation; Cleanup. You are now able to stop the import process after each module, allowing you to control the start time of the subsequent modules precisely. This enables you to limit non-productive operation to the import steps that are really relevant, which leads to a reduction in the duration of the non-productive phase. This import process can be used from Basis Release 4.0B onwards.

Downtime-minimized import: A new type of import developed specifically for importing Support Packages now enables import activities that normally take place during non-productive time, to occur during productive operation. It allows these import activities to be performed in the Import 1 module or in the Cleanup module, thereby further reducing the duration of the non-productive phase. However, the length of the entire import process is increased as a result of the overhead of the new import procedure. The import process that involves the new import procedure can be used from Basis Release 4.6B onwards.

The downtime minimized method is not applicable if the queue cannot be imported at once, or if transports have to be applied before or after the support package import.

© SAP AG E2E200 8-569

The usage of the Downtime Minimized Method should be tested in a sandbox system first before starting in the development system.

© SAP AG E2E200 8-571

© SAP AG 2007

Apply the Support Package Stack with JSPM

In SAP NetWeaver 2004s, the Java Support Package Manager (JSPM) has been introduced, in order to simplify the Support Package management process for Java applications at customer site. The JSPM must be called at the operating system level. In the directory \usr\sap\<SID>\<Instance>\j2ee\JSPM\ call the script go.bat. The JSPM works similarly to transaction SPAM and has similar features.

Useful Links: • Starting point: http://service.sap.com/jspm • SAP Note 891983 - JSPM: Central note • JSPM Media Library

− JSPM User Guide

© SAP AG E2E200 8-572

© SAP AG 2007

Support Package Handling

JSPM

SDM Server

J2EE Server

Deploy Service

Kernel Patch

SDM Patch

SDM Client API

SDMKIT.JAR

*.SCAInbox

SAPEXE.SAR – DB-independent

SAPEXEDB.SAR – DB-dependant

JSPM can update the kernel and other operating system level binaries (like Internet Graphics Server (IGS)) of the AS Java and distribute these parts in cluster environments. If required, JSPM can also update both itself and the deployment service (currently the Software Deployment Manager (SDM)), prior to a system update. As a result, JSPM takes over manual tasks, such as the kernel and binary patch, as well as tasks that were formerly performed by SAPinst, such as the SDM patch, and meets the prerequisites for updating the AS Java as a whole.

Java Software Component Archives (*.SCA) are sent via the SDM client API to the SDM Server. The SDM Server deploys the archives to the J2EE Server.

© SAP AG E2E200 8-573

© SAP AG 2007

Java Support Package Manager (JSPM) -Features

Support Package Management:Validation of dependencies between Software Components and theirSupport Packages

Dependency validation on Support Package/Patch level

Deployment and Installation:Installation of new Software Components

Deployment of up-to-date Support Packages of existing Software Components

Self-Update

Update of SAP kernel

Usability:Unified GUI framework with all other Software Logistics tools

Modification Support for Java Software Components:Co-operation with NWDI

Besides deploying new software components and applying single Support Packages of installed software components, JSPM also provides the following advanced features and functionalities: • Prior to deployment, JSPM performs a prerequisite and dependence check to ensure that

only appropriate Support Packages can be applied into the system. • Updating system kernel and other native parts of the AS Java • Once the prerequisites are met, JSPM is able to apply an entire Support Package stack

(including appropriate kernel patch level) according to the installed Usage Types in the system to be updated in a single step. It also excludes Support Packages that do not belong to any of the installed Usage Types.

• In the case of modified systems, JSPM supplies the standard SAP Support Packages whose software components are modified in the system to the corresponding NWDI track for modification adjustment. Instead of deploying the standard Support Packages of the modified software components, JSPM uses the adjusted Software Component Archives (SCA) from the NWDI for the system update.

© SAP AG E2E200 8-574

© SAP AG 2007

Application of Support Package Stack (Java)

Prior to the application: Check and update the JDK version and JVM settings (SAP Note 723909)EPS inbox: Support Packages along with the Support Package Definition fileBusiness downtime from the start of deployment

Package validation takes place during normal operationInform your users before starting deploymentRestart of JSPM is required after the JSPM self-update

Always as very first package in the deployment queueValidation result and import queue are retainedRestart the deployment of remaining packages in the queueNo further human interactions required

© SAP AG E2E200 8-576

© SAP AG 2007

SAP NetWeaver 2004s

Java Components

ABAPComponents

ABAP Add-On’s(for NetWeaver AS ABAP)

SAP ECC

BI Content

Example: SAP ERP 2005 – Component View

XI Content

EP Content

Java Web Applications

Additional Components

SAP ECC 6.0(Details see next slide)

E-Recruiting 6.0FINBASIS 6.0

SEM 6.0LSO (FE) 6.0

inclusive:

WFM_Core 2.0

cProject Suite 4.0

SAP Catalog 2.0

E-Recruiting 6.0

FINBASIS 6.0

SEM 6.0

LSO (FE) 6.0

SAP SRM(Available as ECC-Add-Onand stand alone server)

BI Content 7.0x

XECO 5.0

Biller Direct 6.0

LSO (CP) 6.0

SAP XSS 6.0

ELSTER 2.0

XI Content for Applications

Business Packages

SAP SRM 5.5

Front End


SEM FrontendComponents

LSO (OP) 6.0

SAPGUI 6.20/ 6.40

SAP Easy Document Management 6.0

OpenPSfor MS Projects

cProjectsECL Viewer

LSO (AE) 6.0

In the last years SAP Solutions became more and more complex. System Landscapes are growing and the number of software components inside a product is growing.

Therefore, it is getting more and more difficult to keep track of maintenance activities and software versions in the whole system landscape.

© SAP AG E2E200 8-577

© SAP AG 2007

Better Handling of Customer Maintenance Processes

Display current level and recommended level

Approve and download

Import

Test


Planning of maintenanceSupport Packages and StacksHotNews

Administration

Provide transparency

The SAP Solution Manager is a central entry point for all maintenance activities. It provides transparency of the software versions for the whole solution.

© SAP AG E2E200 8-578

© SAP AG 2007

Maintenance Optimizer – Technical ProcessDescription

Solution-

ManagerNWBI

SAPERP

NWBI

Service

Market

Place

DownloadBasket (part of SMP)

DownloadManager

1

2

4

3

5

6

Check Versions

Select Files

Confirm Files

Download FilesImplementSupport

Packages

Maintain Status

This picture provides an overview of the Maintenance Optimizer procedure. The administrator checks the support package levels in the SAP Solution Manager and starts a

new maintenance process from there. After selecting a system, the SAP Solution Manager provides a link to the SAP Service

Marketplace where the latest support packages can be selected and added to the download basket.

In the next step, there is another link from the SAP Solution Manager into the SAP Service Marketplace. Now, the administrator has to confirm the patch files in the download basket.

The confirmed patch files can now be downloaded to the administartor‘s local PC. From there, they can be uploaded and implemented in the managed systems.

Finally, the status of the maintenance activity is maintained in the SAP Solution Manager. All activities except for the download and implementation of the support packages can be

done in the SAP Solution Manager. There is no need to search for patches in the SAP Service Marketplace.

© SAP AG E2E200 8-580

© SAP AG 2007

Create a New Maintenance Transaction (3/3)

1. Start transaction SOLUTION_MANAGERSOLUTION_MANAGER

2. Go to Change Management -> Support Package Stacks

3. Choose Maintenance Optimizer

The Maintenance Optimizer is started from transaction SOLUTION_MANAGER. Select your solution and go to Change Management Support Package Stacks. Select a system and check the support package level. Press the button Maintenance Optimizer to start a new maintenance process.

© SAP AG E2E200 8-581

© SAP AG 2007

Step 1: Plan Maintenance

3. Choose Continue

2. You can add business partners and documents

1. Choose Product Version

Start Maintenance Planning: • Specify the necessary information for product maintenance. Mandatory fields are indicated

with a red asterisk. − Short Text: Enter a descriptive text. By default, the text “New Maintenance Optimizer

procedure” appears. − Product version: You can choose one of the product versions from the current solution.

The Maintenance Optimizer determines the selection of product versions based on the systems assigned to your solution.

− System: Once you choose a product version, the Maintenance Optimizer displays the systems assigned to that product version. Select the system(s) for which you want to perform product maintenance.

• Choose Continue.

© SAP AG E2E200 8-582

© SAP AG 2007

Step 2: Select Files

3. Choose Continue

1. Go to area of chosen product version in SAP Support Portal

2. Add files to Download Basket

This step will be enhanced with an automatic calculation of the necessary files.

2. Select Files • Select the product maintenance files for your system. To do this, use the link to navigate to

the SAP Software Distribution Center of the SAP Service Marketplace. • The Maintenance Optimizer opens the SAP Service Marketplace in a new browser

window. • The Maintenance Optimizer navigates directly to the appropriate download area based on

the product version which you selected in the previous step. • For further information and for help in placing items into your Download Basket, see the

documentation in the SAP Service Marketplace. • Once you have selected the files you wish to download in the Maintenance Optimizer,

choose Continue.

© SAP AG E2E200 8-583

© SAP AG 2007

3. Continue

Step 3: Download Files

1. Go to Download Basket

2. Confirm files inDownload Basket

3. Download Files • Before you can download the files, you must first confirm your selection in the

Maintenance Optimizer. To do this, choose Confirm Selection in the Maintenance Optimizer.

• In the following screen, select the files and choose Copy/Authorize. • By confirming your selection, the files are assigned to the maintenance procedure and

released for download. • Now, you can download the files using the SAP Download Manager. For more information

about using the SAP Download Manager, see the documentation in the SAP Service Marketplace.

• In the following screen, select the files and choose Confirm Download. • By confirming your selection, the files are assigned to the maintenance procedure and

released for download. • Now, you can download the files using the SAP Download Manager. For more information

about using the SAP Download Manager, see the documentation in the SAP Service Marketplace.

© SAP AG E2E200 8-584

© SAP AG 2007

Step 4: Perform Implementation

1. Set status of implementation to In Progress

4. Continue

3. Set status of implementation to Completed

2. Look for details and request side

effect notes

4. Perform Implementation • After downloading the files, perform the required maintenance in your systems. • If you assigned systems at the beginning of the procedure, the Maintenance Optimizer lists

these systems for you. You can enter the start date and end date for the implementation and indicate the status of the procedure.

• The Maintenance Optimizer displays an overview of the files which you selected in the previous step. For each Support Package, you can view the documentation of the corrections and their side-effects by clicking the corresponding link.

• Once you have performed the required maintenance in all selected systems, you can complete the maintenance procedure. To complete the procedure, you must first set the implementation status for each system assigned to the procedure to Complete.

• Choose Continue.

© SAP AG E2E200 8-585

© SAP AG 2007

Step 4: Perform Implementation

The SAP Download Manager is a PC tool which is installed on the administartor‘s PC. The Patches are downloaded to the PC where the SAP Download Manager was called and can

then be implemented in the system, e.g. with transaction JSPM.

© SAP AG E2E200 8-586

© SAP AG 2007

Step 5: End Maintenance

Complete maintenance transaction

5. End Maintenance • Once you have successfully finished the maintenance of your systems, complete the

procedure for product maintenance. Once you set the status to Complete, the procedure can no longer be changed.

© SAP AG E2E200 8-587

© SAP AG 2007

Maintenance Optimizer – Monitoring

1. Start transaction /n/tmwflow/maintenance

2.Choose parameters

3.Choose Execute

4.Results

Transaction /TMWFLOW/MAINTENANCE Product maintenance reporting helps give you an overview of all product maintenance

procedures in your SAP Solution Manager system. You can simultaneously view procedures which belong to several different solutions and you can also view closed or withdrawn procedures.

You can use the reporting function to: • Create an overview of product maintenance procedures which match specific criteria such

as status or priority • Navigate to the corresponding step of an open product maintenance procedure in the

Maintenance Optimizer • Create an overview of product maintenance procedures and save the overview to a local

file for further processing

© SAP AG E2E200 8-588

© SAP AG 2007

SAP Support Portal: Contact Person Assignment

Your S-User is the user-ID assigned to you by SAP which you use to log on to the SAP Support Portal.

Your system administrator must have performed the following SAP Implementation Guide (IMG) activities:

Maintain User for Communication with SAP Service and SupportAssign S-user for SAP Support Portalfunctionality or with the transaction AISUSER

Your S-User must be assigned to the same customer or corporate number as the S-User which your administrator entered in the SAP-OSS RFC destination. If this is not the case, the Maintenance Optimizer will not be able to read your download basket

Always log on to the SAP Support Portal with the same S-User which is assigned to your Solution Manager user. If you do not do this, the Maintenance Optimizer will not be able to confirm and approve any files you place in that S-User’s Download Basket.

© SAP AG E2E200 8-589

© SAP AG 2007

Configure SAP Download Manager

The SAP Download Manager must be configured. In the upper section, enter the address of the SAP Service Marketplace, your S-User and the

password. In the lower section, enter the proxy settings to connect to the Internet.

© SAP AG E2E200 8-590

© SAP AG 2007

Maintenance Optimizer - Outlook

The Maintenance Optimizer will be continuously enriched. Planned Improvements are:

Possibility to use tools other than the Download Manager for download Automatic calculation of Delta between latest available stack and current software at customer installationIntegration with Change Request Management (planning, reporting, monitoring) as a guided procedureIntegration with Enhanced Change and Transport System (CTS+) and Software Lifecycle Management ToolsFurther information is provided in the SAP Service Marketplace under the link http://service.sap.com/solman-mopz

© SAP AG E2E200 8-592

© SAP AG 2007

SAP Launched Three New Note Service Offerings

1. SAP HotNewsContain solutions for customer problems with very high priority, such as systems standstills or data lossAllow customers to filter and display SAP HotNews for their chosen components

2. SAP TopNotesInform you about potential hot spots in your projectsPublished on a monthly basis Represent the ten most important SAP Notes for each componentReviewed monthly by experts in the relevant departments and updated based on the current SAP Note customer usage rate

3. SAP FAQNotesPresent the most frequently asked questions for particular topics with brief and 'to-the-point' answersIdeal place to start looking for a quick and easy answer before embarking on a full-blown search

SAP HotNews are priority 1 (very high priority) SAP customer notes. These notes tell you how to resolve or avoid problems that can cause the SAP system to shut down or lose data. If you are affected by these problems, you must ensure that you are aware of these notes.

SAP TopNotes are the most important notes of a component or a subcomponent reported on successfully closed customer support messages. The selection of the 10 most successful notes is done regularly, on a monthly basis, in a semi-automatic process. The process is described in note 557703

© SAP AG E2E200 8-593

© SAP AG 2007

Proactive and Reactive Channels

ProblemProblem

Management

IncidentService Desk/Incident

Management

Request and Commitment for Change• Emergency

• Maintenance – reactive / proactive Notes Implementation

Application Management

ProblemProblem

Management

IncidentMonitoring Incident

Reactive Channel

Support Desk System Monitoring

Top Notes

Hot News

Proactive Channel

SAP Service MP

e.g.

Program Errors (ABAP)

Update Errors

Test and Implementation of Change• Note Assistant

Technology Team

© SAP AG E2E200 8-594

© SAP AG 2007

SAP HotNews Inbox in SAP Solution Manager

Hot

New

sP

lann

ing

SAP HotNews Inbox (DSWP)

Retrieve relevantHotNews from SMP*

Postpone HotNews for later administration

Set HotNews to not relevant (not applicable, read only)

Filter HotNewsview

Transaction Processing (CRMD_ORDER)Create change request

Process change request – start standard “urgent correction process”

Log activities

Hot

New

sP

roce

ssin

g

Check change request data

Approve change request for HotNews

Based on infrastructure (see prerequisites)

* SAP Service Marketplace

© SAP AG E2E200 8-595

© SAP AG 2007

Best Practice for HotNews and TopNotes

Set up regular procedures to check for new HotNews:HotNews Weekly cycleTopNotes Monthly cycle

Solution Manager: Define a responsible person to check for new HotNews and create Change Requests (e.g. Change Control Engineer)Change Requests are forwarded to the module responsiblesChoose components where a customer opened OSS calls in last 3 – 6 months Get SAP Service Marketplace Newsletter weekly

© SAP AG E2E200 8-597

© SAP AG 2007

Maintenance Management – SAP HotNews

Retrieve SAP HotNews from SAP Service Marketplace(Transaction: DSWP, Operations area, Change Management tab, HotNewsInbox, New tab)

Retrieve relevant SAP HotNews using Refresh button

SAP HotNews is retrieved for: • matching application components (as assigned to logical component) in combination with • matching product version of the logical component and software component version of the

source system (here TW2) Displayed SAP HotNews Component is always the primary component

© SAP AG E2E200 8-598

© SAP AG 2007


12

3

Filter settings in SAP HotNews Inbox(Transaction: DSWP, Operations area, Change Management tab, HotNewsInbox, New/Postponed/Not relevant tab)

Filter displayed data according to your areas of responsibility

Hide the filter to save space. Check filter settings first, if you miss Entries. The active filter indicated by “Filter is Active”

at the top of the News tab (not shown).

© SAP AG E2E200 8-599

© SAP AG 2007


1

2

Create change request for SAP HotNews (1/3)(Transaction: DSWP, Operations area, Change Management tab, HotNewsInbox, New tab)

Create change request for selected SAP HotNews in order to apply for SAP HotNews installation for the respective system (here, TW2).

© SAP AG E2E200 8-600

© SAP AG 2007


Fast Entry– SAP HotNews

Transcation Data/Context tab– Solution-specific informationIncluding SAP Hot News (see Notes)

3

4

Create change request for SAP HotNews (2/3)(Transaction: CRMD_ORDER)

Change request pre-filled with SAP HotNews and solution-specific information including notes requested for installation

© SAP AG E2E200 8-601

© SAP AG 2007


Create change request for SAP HotNews (3/3)(Transaction: DSWP, Operations area, Change Management tab, HotNewsInbox, New tab)

Change requests and their status can be viewed at any time

Change request display is possible: • per system • per logical component (as shown) • for status values except confirmed/rejected • Activity status change traced and visible on the Log tab

© SAP AG E2E200 8-602

© SAP AG 2007


1

2

Postpone SAP HotNews (1/2)(Transaction: DSWP, Operations area, Change Management tab, HotNewsInbox, New tab)

Postpone SAP HotNews for administration at a later point of time

© SAP AG E2E200 8-603

© SAP AG 2007


Postpone SAP HotNews (2/2)(Transaction: DSWP, Operations area, Change Management tab, HotNewsInbox, Postpone tab)

Comment on the reasons/background for postponing SAP HotNews to increase transparency

Comments are listed in chronological order. Log allows status change tracking for respective SAP HotNews

© SAP AG E2E200 8-604

© SAP AG 2007


1

2

3

Set postponed SAP HotNews back to New(Transaction: DSWP, Operations area, Change Management tab,HotNews Inbox, Postpone tab)

Comment handling after status change Comment history is saved per status (New, Postponed, Not Relevant) History records proposed as default description for new comment

© SAP AG E2E200 8-605

© SAP AG 2007


1

2

SAP HotNews Set to Not Relevant(Transaction: DSWP, Operations area, Change Management tab, HotNewsInbox, Not Relevant tab)

Set SAP HotNews to not relevant if – after thorough investigation –they are not applicable for the system in your solution or are of type information only.Comment on the reasons/background setting SAP HotNews to not relevant to increase transparency.

SAP HotNews that are not relavant can be set back to status New

© SAP AG E2E200 8-606

© SAP AG 2007


SAP HotNews activity logging(Transaction: DSWP, Operations area, Change Management tab,HotNews Inbox, Log tab)

Every activity resulting in a status change (such as New -> Postponed) is recorded.Creation of change requests is also recorded.

Click on comment icon to see complete comment

© SAP AG E2E200 8-607

© SAP AG 2007

Maintenance Management: Unit Objectives


Know the SAP Maintenance Strategy

Describe all types of patches delivered by SAP

Explain the support package stack strategy

Execute side effect Reporting for a Support Package Queue

Estimate the impact of a support package import into a critical system

Use the software lifecycle management tools to implement patches and find information on current patch levels

Explain the additional benefit of the SAP Solution Manager in the maintenance process

© SAP AG E2E200 8-608

Exercises

Unit: Maintenance Management

At the conclusion of this exercise, you will be able to: • Find version information for a customer solution • Find information on support packages in the SAP Service Marketplace • Use the Maintenance Optimizer and HotNews Inbox in SAP Solution

Manager to plan and execute maintenance tasks

For this exercise you need your own S-user to access the SAP Service Marketplace!

8-1 Detection of version information

8-1-1 Logon to the Solution Manager system TT4 and check the support package level for the ECC and CRM systems in your solution. Where can you find this information? Answer: __________________________________________________ What is the release and support package level for the component SAP_APPL of the ECC Server? Answer: __________________________________________________ What is the release and support package level for the component BBPCRM in the CRM Server? Answer: __________________________________________________

8-1-2 Check the applied SAP Notes for the ECC Server TT5. What is the transaction name? Answer: ______________________________________________ Go to the Notes Browser and display all SAP Notes with status Completely Implemented. How many notes are applied? Answer: ______________________________________________

8-1-3 Check the version information for the JAVA stack of system TT5 on the Component Info site. What is the URL? Answer: ______________________________________________

© SAP AG E2E200 8-609

Which support package and patch level is applied for the software component SAP_ESS? Answer: ______________________________________________

8-2 Find information in the SAP Service Marketplace 8-2-1 Logon to the SAP Service Marketplace with your S-User. Where can you

find information on the available Support Package Stacks? Answer: ________________________________________________

8-2-2 Check the latest Support Package Stack for mySAP ERP 2005. What the name of this stack? Answer: ________________________________________________ What is the latest support package for SAP_APPL in this stack? Answer: ________________________________________________ Which SAP_APPL support packages are missing in the current solution of TT5? Answer: ________________________________________________

8-2-3 Request the list of side-effects for the missing SAP_APPL support packages. If all SAP_APPL support packages are imported in TT4, check the side-effects for the latest one. What is the URL? Answer: ________________________________________________

8-3 SAP Maintenance Optimizer 8-3-1 Create a new maintenance activity with the SAP Maintenance Optimizer.

Select your solution and go to Change Management Support Package Stacks. Create a new maintenance activity by clicking on the button Maintenance Optimizer. Enter the following data: Short text: CRM Maintenance ## (## is your user number) Product version: SAP CRM 5.0 Select the logical component Z_E2ECC_CRM Save your input and exit

8-3-2 Check all completed maintenance activities for the solution E2ECC Demo Solution in the reporting transaction of the Maintenance Optimizer. What is the transaction name? Answer: __________________________________________________ Which support packages were downloaded in these maintenance activities? Answer: __________________________________________________

8-4 HotNews Inbox 8-4-1 In your solution select Change Management HotNews. Look at the list

of SAP HotNews for the SAP ECC system TT5.. a) When was the list downloaded from the SAP Service Marketplace? Answer: __________________________________________________ b) Select one note and set it to Postponed. Enter a comment.

© SAP AG E2E200 8-610

c) Select another note and set it to Not Relevant. Enter a comment. d) Check if your activities were logged in the folder Log.

8-4-2 Create a Change Request to implement a note a) Check if there are already HotNews in Change Requests. b) Select a note and create a Change Request to implement it. c) In the change request enter the following data:

- Sold-to party: Your User - Requestor: Your User - Change Manager: Your User - Ibase / Component: Production Simulation - Priority: High - Subject: Urgent Correction (Maintenance) - Description of Change: Enter a description - Save the data

d) Go to Transaction Data Customer fields and expand the tree structure. Right mouse click on the note number and follow the link to the note in the SAP Service Marketplace.

© SAP AG E2E200 8-611

Solutions

Unit: Maintenance Management

8-1 Detection of version information

8-1-1 Logon to the Solution Manager system TT4 and check the support package level for the ECC and CRM systems in your solution. Where can you find this information? Goto transaction SOLUTION_MANAGER Change Management Support Package Stacks. Expand the systems in your solution in order to see the support package level. What is the release and support package level for the component SAP_APPL of the ECC Server? The release of SAP_APPL is 600. The support package level can be seen in the list. What is the release and support package level for the component BBPCRM in the CRM Server? The release of BBPCRM is 500. The support package level can be seen in the list.

8-1-2 Check the applied SAP Notes for the ECC Server TT5. What is the transaction name? Logon to client 800 in the SAP ECC system TT5. The transaction name is SNOTE (SAP Note Assistant). Go to the Notes Browser and display all SAP Notes with status Completely Implemented. How many notes are applied?

Click on the button for the Notes Browser ( ). In the next screen select Implementation Status = Completely implemented and execute. The result contains roughly 20 notes.

8-1-3 Check the version information for the JAVA stack of system TT5 on the Component Info site. What is the URL? The URL is http://<hostname>:55000/sap/monitoring/ComponentInfo. The trainer will give you a user to logon. Which support package and patch level is applied for the software component SAP_ESS? Search for the text SAP_ESS in the component info. The patch level is part of the version string. 600.0 is the component release. The next number is the support package level. The next number is the patch level.

© SAP AG E2E200 8-612

8-2 Find information in the SAP Service Marketplace 8-2-1 Logon to the SAP Service Marketplace with your S-User. Where can you

find information on the available Support Package Stacks? The URL is http://service.sap.com/sp-stacks. Logon with your own S-User.

8-2-2 Check the latest Support Package Stack for mySAP ERP 2005. What the name of this stack? In the lower part of initial page you find a link for mySAP ERP 2005. Follow that link. In the next window the latest target stack is pre-selected in the field Target Stack (see screenshot below). Write down the name.

What is the latest support package for SAP_APPL in this stack? Click on the button Show Stack Information. In the next screen search for the component SAP_APPL. Write down the support package level. Which SAP_APPL support packages are missing in the current solution of TT5? Calculate the difference between the latest support package level for SAP_APPL which is available in the SAP Service Marketplace and the support package which is applied in the system TT5 (see exercise above).

8-2-3 Request the list of side-effects for the missing SAP_APPL support packages. If all SAP_APPL support packages are imported in TT4, check the side-effects for the latest one. What is the URL? Go to the URL http://service.sap.com/side-effects. Enter the product and product version. On the next screen enter the support packages which you want to import. Submit your request. You will be notified by email when the result is available.

© SAP AG E2E200 8-613

8-3 SAP Maintenance Optimizer 8-3-1 Create a new maintenance activity with the SAP Maintenance Optimizer.

Select your solution and go to Change Management Support Package Stacks. Create a new maintenance activity by clicking on the button Maintenance Optimizer. Enter the following data: Short text: CRM Maintenance ## (## is your user number) Product version: SAP CRM 5.0 Select the logical component Z_E2ECC_CRM Save your input and exit

8-3-2 Check all completed maintenance activities for the solution E2ECC Demo

Solution in the reporting transaction of the Maintenance Optimizer. What is the transaction name? In TT4 go to the transaction /TMWFLOW/MAINTENANCE. Select the button Completed and choose the solution E2ECC Demo Solution. Press Execute Which support packages were downloaded in these maintenance activities? In the list of the completed maintenance activities double click on one activity. On the next screen click on the button Continue in the lower part of the screen. Click Continue until you are in step number 4 of the maintenance activity Perform Implementation. The downloaded support packages are in the block Copied and confirmed download files.

© SAP AG E2E200 8-614

8-4 HotNews Inbox 8-4-1 In your solution select Change Management HotNews. Look at the list

of SAP HotNews for the SAP ECC system TT5. a) When was the list downloaded from the SAP Service Marketplace?

Under the folder New you see the number of available HotNews for each system of the solution and when the list was downloaded from the SAP Service Marketplace.

b) Select one note and set it to Postponed. Enter a comment. Select a note and click on Postpone. Then goto the folder Postponed and add a comment for this note.

c) Select another note and set it to Not Relevant. Enter a comment. Select a note and click on Not Relevant. Then goto the folder Not Relevant and add a comment for this note.

d) Check if your activities were logged in the folder Log. Go to the folder Log and check the information which was recorded.

8-4-2 Create a Change Request to implement a note a) Check if there are already HotNews in Change Requests.

Under the folder New you see this information in the column HotNews in Change Requests.

b) Select a note and create a Change Request to implement it. Select a note and click on the button Create Change Request. A maintenance project must be assigned to the solution for which Change Request Management is activated.

c) In the change request enter the following data: - Sold-to party: Your User - Requestor: Your User - Change Manager: Your User - Ibase / Component: Production Simulation - Priority: High - Subject: Urgent Correction (Maintenance) - Description of Change: Enter a description - Save the data

d) Go to Transaction Data Customer fields and expand the tree structure. Right mouse click on the note number and follow the link to the note in the SAP Service Marketplace.

© SAP AG E2E200 9-617

© SAP AG 2007

Contents:

Theory of Software Testing

SAP Test Workbench

Test Management with SAP Solution Manager

Test Automation with eCATT

SAP Code Inspector

Volume Test

System Copy Procedures

Test Data Migration Server

Test Case Selection

Test Management

© SAP AG E2E200 9-618

© SAP AG 2007

Test Management


Explain different types of tests and test strategies

Describe the features of the Test Workbench and eCATT

Understand the benefits of SAP Solution Manager and how SAP Solution Manager is integrated with HP Quality Center

Use the SAP Code Inspector to perform automated syntax checks

Describe how to prepare test systems by performing system copies or by using the SAP Test Data Migration Server

Guideline how to select test cases

© SAP AG E2E200 9-619

© SAP AG 2007

Test Management Unit Overview Diagram

Test ManagementLesson 1: Theory of Software Testing

Lesson 2: SAP Test Workbench

Lesson 3: Test Management with SAP Solution Manager

Lesson 4: Test Automation with eCATT

Lesson 5: SAP Code Inspector

Lesson 6: Volume Test

Lesson 7: System Copy Procedures

Lesson 8: Test Data Migration Server

Lesson 9: Test Case Selection

© SAP AG E2E200 9-620

© SAP AG 2007

Change is a Fundamental Principle – Testing a necessity

There are many changes in the solution life cycle - and every change requires testing

Business inspired changes:Mergers and AcquisitionsContinuous ImprovementsFunctional Upgrades…

IT inspired changes:Technical UpgradesSupport PackagesNotes...

Test effort

Business inspired changes

IT inspired changes

SAP Implementation: • Executive & LOB sponsorship • Committed vendor/SI support • Project budget

SAP in Production: • Silo teams, each with their own focus • Frequent Changes, Updates & Upgrades, SOX • Limited Vendor, SI or other resources Usually 80% reduction in team size

© SAP AG E2E200 9-621

© SAP AG 2007

Integration TestIntegration Test

Testing in Projects – The V-Model

Detailed (Technical) Design

Development

Unit Test

Integration Test

User Acceptance Test

Functional Design Business Blueprint

Requirements Doc

Functional Requirement, Business Case

Functional Test

Config Owner Test,can be automated

OKFunctional

sign offValidation

Verification

ValidationVerification

Validation

Regression Testing (automated)Existing Business Processes

Validation

Over the course of a project, the requirements are refined and documented in a business process blueprint, consisting of a functional and technical design. These documents are the basis for development. The test phases are validations of these development goals.

The project testing is managed by the project test coordinator (referenced to as test coordinator).

Testing Phases • Project testing consists of the testing phases:

A Unit Test is: • a validation of the technical design • a test of an individual program unit • Executed by the developer during development

An Integration Test is: • a validation of the functional design (business blueprint) • a test of the entire system and the integration of all units • executed by the service line with optional involvement of the LoB

A Final User Acceptance Test is: • a validation of the requirements and usability

© SAP AG E2E200 9-623

© SAP AG 2007

Testing in Projects

Implementation ProjectProject

PreparationRealization

Development, TestBusinessBlueprint

Final Preparation and Go Live

Test Concept

Unit Test (Debugging)

ReviewReview

Regression Test

Use

r Acc

epta

nce

Test

OK

OK Functionalsign off

Systemsign off

Test planning

Inte

grat

ion

Test

BusinessBlueprint Doc

Test Case Development

Bug

Fix

ing

Bug

Fix

ing

Testing & Bug Fixing is ~30% of total project effort

On average, testing and bug fixing consumes 30% of the project resources and duration. Testing should be planned accordingly.

The high level testing phases are scheduled during project planning and preparation. The test coordinator plans the test phases in detail and supports the project manager in planning.

During the business blueprint phase, the test coordinator develops the test concept with support from the technical implementation team and the business analyst. The test coordinator ensures that while the business blueprint structure is built, test cases are described and developed according to the business processes. Testers for the first test phase are nominated and invited.

Before each test phase, an update of the test concept is required. The test coordinator verifies the test cases and ensures the creation and update of them. The test coordinator creates phase a test plan and tester assignment for each test.

© SAP AG E2E200 9-624

© SAP AG 2007

Regression Testing

Project A

Project B2

Project C

Approval Release Delivery

Patches, NotesProject B1

Repairs

Regression TestTest Automation

(eCatt + 3rd party tool)

Blueprint Dev Test

Blueprint Dev Test

Blueprint Dev Test

Blueprint Dev Test

Dev Test

Service Packs,

OK Systemsign off

Project Changes

Business Scenario

Process A44

Process A42

Process A43

Test

Test

Business Scenario

Test Process B34

Process B32

Process B33

Test

Test

Test

…. Business Scenario ….

OKFunctional

sign off

Core Business Processes

Regression Testing: • Regression testing ensures that existing business processes are not affected or changed

unintentionally by maintenance changes or projects going live. Regression tests are, typically, automated test cases (eCatt test script, or 3rd party test script tool). A manual test case description is the basis for an automated test script.

• The Test Coordinator manages the regression tests.

© SAP AG E2E200 9-625

© SAP AG 2007

Technical System Tests

Technical function tests check the functionality of the technical ingredients in the production environment. (focus: basis components)

System failure test (e.g. Network or Hardware Problems)

Disaster and Recovery test

Backup and Restore test

System Administration test

Print and fax test

GoingLive Check

In technical system tests, the complete infrastructure consisting of database, application server, frontends, network, printer, etc. is checked.

© SAP AG E2E200 9-626

© SAP AG 2007

Performance Tests

Performance Tests:Response time of important transactionsRuntime of critical background jobs

Load and Stress Tests:During a Load Test, the performance of a system, depending on the amount of users working simultaneously in it, is tested and monitored. Therefore, Virtual Users are deployed.

A Stress Test analyses the performance of a system under extreme conditions, e.g. by creating mass data.

Period-end closing test

Goal of both Load and Stress Testing is the identification of so-called „bottlenecks“, that slow down the system.

In performance tests, the throughput and response times of the system are measured. Performance tests are an important extension of pure functional tests. It is a prerequisite for the execution of performance tests that the functional correctness of the application is tested.

© SAP AG E2E200 9-627

© SAP AG 2007

Test Planning (1)

How will testing be performed?Manual testsAutomated test scripts

What tools can be used?Test Organization:

SAP Test WorkbenchSolution Manager – Business Process Repository3rd party tools like HP Quality Center

Test Automation:CATT - Computer Aided Test TooleCATT 3rd party tools like Compuware, Mercury Quick Test Pro, Mercury Load Runner

For Textual Cases:Process descriptionsTemplates for test casesTest case review is useful (correctness, completeness, grade of details)

© SAP AG E2E200 9-628

© SAP AG 2007

Test Planning (2)

Who will test?Customer’s employees

Project team member / IT-member

Department / User

Internal revision

Customers basis team

External consultants

Who is testing when?

Use of the 4-eyes-principal?

What skills do the testers have?

Management commitment for testing available?

© SAP AG E2E200 9-629

© SAP AG 2007

Requirements for a test case description

Contents:Test case: <Z_naming convention> Title: <Test case title>Description

PreparationExecutionChecking / expected result

Extra notes

© SAP AG E2E200 9-631

© SAP AG 2007

SAP Test Workbench – Overview

Test Organizer

eCATT

CATT

Test Workbench

Migration

Status information

Management

Status information

Management

3rd-party test tools

Open Interface

Test Management & Execution

Test Automation, Recording

Test Workbench was first realized for the organization of release tests in SAP Product development.

Integrated in SAP Solution Manager, mySAP Business Suite / SAP Netweaver → No extra costs

SAP-Tool to organize and perform tests: • during an SAP Implementation project • within Application Change Management process

Parts of Test Workbench: • Test Organizer • Computer Aided Test Tool (CATT) • eCATT (since WebAS 6.20)

© SAP AG E2E200 9-632

© SAP AG 2007

Testing – Process in Detail

TestExecution

Assignment of test packages

to testersoperation queue of

a single tester

Collection of test cases

Project/business relatede.g. Implementation CRM 4.0

Interaction center

Selection of test cases Aim and time relatede.g. for applying a

specific Support Package

Test analysis

TestersTest packageTest packageTest packageTest packageTest packageTest package

Test plan

Project structure

with assigned test cases

Test catalog, Project or Solution Directory structure: • Hypertext-Structure • Collection of Test cases

Test plans: • View on one Test catalog • Contains all Test cases for one Test

Test package: • Person- and time oriented view on a Test plan • Contains all Test cases one Tester has to work with

Test case: • Business process step / Process chain • manual Test case / CATT-Module / CATT-Script / eCATT-Script

© SAP AG E2E200 9-633

© SAP AG 2007

A test catalog is a directory structure to store test cases.In the Configuration phase, create a test catalog and assign test cases.

Testing – Create and Assign Test Cases

There are different test case types to assign: • CATT (automated / regression testing) • eCATT Test Configuration (automated / regression testing) • External Application (e.g. attached files) • Function Module Test (normally not used outside SAP development) • Manual test case (test description in SAPscript) • Test Document (e.g. upload of a Microsoft Office document)

© SAP AG E2E200 9-634

© SAP AG 2007

Systematic storage of test cases for testing business processesAdministration of manual and automated testsGeneration of project-specific test plans and test packagesAssignment of testers, who will find the assigned test packages in their work lists

Testing – Generate Test Plans and Test Packages

Test plans represent a single test event, for example, an integration test cycle in a project. All test cases which are relevant for this test event are assigned to a test plan.

Test packages are assigned to certain testers. Go via EASY ACCESS Menu TEST Β TEST WORKBENCH Β TEST ORGANIZER Β

TEST PLAN MANAGEMENT (Transaktion STWB_2). Choose the Test plan you want to create Test packages for.

© SAP AG E2E200 9-635

© SAP AG 2007

Access to user specific worklistTest execution in accordance with test case descriptionLog of test results and statusCreation of a Support Message, if necessary

Test Execution

Transaction STWB_WORK provides a user specific worklist to the testers. Here, they can find the test case descriptions, execute the tests and log the test success or failure. Furthermore, they can make notes or create Service Desk messages.

© SAP AG E2E200 9-636

© SAP AG 2007

Detailed views of test progress and test resultsGraphics and reports for all test plans in a projectExport of test results into office applications

Test Monitoring and Reporting

The test coordinator can track the status of the test progress in different transactions: … on the level of: • Projects, Business Scenarios and Processes

− SOLAR_EVAL • Test plans and test packages

− SOLAR_EVAL, STWB_2, STWB_INFO

© SAP AG E2E200 9-637

© SAP AG 2007

Administration of Problems during a testDetailed Analysis and Prioritization of ProblemsAssignment of processors via Test Coordinator

Problem Ticket Handling

Testers can create Service Desk messages to track failed test cases.

© SAP AG E2E200 9-638

© SAP AG 2007

Test Report

Microsoft Word Document

Examples for usage of a test report:

Formal acceptance of a test phaseDocumentation obligation in validated areas (FDA Compliance)

(Transaction: STWB_2, menu Go to -> Test Report)Generation of a Test Report for one Test PlanMS Word Document containing all Test Plan informationEnhanced traceability of test resultsVarious selection and assembly options for Test Report

After a test phase, a test report can be created. This is often required in validated areas (FDA compliance).

© SAP AG E2E200 9-639

© SAP AG 2007

Benefits of the SAP Test Workbench

The SAP Test Workbench provides the following benefits:Guarantees reusability for manual and automated test casesEasy test case description and test result documentationLogging of who has tested what, when and with which result Test results are reproducibleSupport for systematic testingWell-designed monitoring possibilities for Test Manager (Status analysis)Simple handling

© SAP AG E2E200 9-642

© SAP AG 2007

Additional Benefits of the SAP Solution Manager

SAP Solution Manager:Provides the business process structure as central repository for test casesIs a central system administration platform and provides RFC Connections to the satellite systemsProvides integration with Service Desk, Change Request Management, Implementation

© SAP AG E2E200 9-643

© SAP AG 2007

Testing in SAP Solution Manager

Central definition and preparation of test plans and packages.Assign test packages to Testers.

Testers find test packages in theirpersonal Work-list and execute thetest, for example, using eCATTs.

Check the status of your tests in the Status Info System.

Business Blueprint & Configuration

Test Plan

BC Register in Web Shop

Select Product

Update Shopping Basket

Business-to-Consumer

Create Order

Process Order

Order Processing

Selected Business Scenarios

Internet Sales: B2C

Business Processes

Register in Web Shop

Select Product

Update Shopping Basket

Business-to-Consumer

Create Order

Process Order

Order Processing

Business Processes

Internet Sales: B2C

Selected Business Scenarios

You organize tests after you have created a Business Blueprint and made initial configurations in the Realization phase.

The first step of more detailed test organization is creating a test plan. During the Business Blueprint phase, you have created a project structure, consisting of business scenarios, processes and process steps. You have then assigned transactions and test cases to process steps. When you create a test plan, the system will offer you this project structure as a basis for your test plans. In addition, the system will also provide all those manual and automated test cases you have already assigned to processes or process steps, and you can select them for your test plan.

© SAP AG E2E200 9-644

© SAP AG 2007

Assign test casesIn the Configuration phase (SOLAR02), assign test cases to each scenario, process (e.g., for integration testing) or even process step (e.g. for unit testing).

Leverage Business Process Definition

© SAP AG E2E200 9-645

© SAP AG 2007

Define Project System Landscape:In Solution Manager Project Administration (SOLAR_PROJECT_ADMIN):

allocate physical systems for all system roles relevant for testing (e.g. Quality Assurance System) define if central system for storage of test cases is obligatorydefine templates for test case description and test notes

Define project structure:In Business Blueprint phase (SOLAR01), create a project structure, consisting of business scenarios, processes and process steps. The system will offer you this project structure as a basis for your test plans.

Project System Landscape

© SAP AG E2E200 9-646

© SAP AG 2007

Central Test Co-ordination

Example: Sales Order Processing

Create Sales Order

Availability Check

Credit Check

Receive Order

Order Confirmation

Maintain Status

SAP CRM SAP APO SAP R/3T

est

Exe

cuti

onT

est

Mgm

t.


Configure Products

Determine Conditions

Replicate Order

Business processes are often distributed across different systems. Therefore, it makes sense to store all the test cases in a central administration system.

© SAP AG E2E200 9-647

© SAP AG 2007

Solution Manager

Integration with other Tools in SAP Solution Manager

Test Organizer

eCATT

Test Workbench

Status information

Management

Status information

Management

Test Management & Execution

Test Automation, Recording

Implementation ContentProject Structure


Service DeskIssue

ManagementMigration

CATT

The Test Organizer is integrated with other tools in SAP Solution Manager: Implementation Content Project Structure

• Service Desk Issue Management • Change Request Management

© SAP AG E2E200 9-648

© SAP AG 2007

Interface to HP Quality Center

SAP Solution Manager HP Quality CenterSe

rvic

e De

sk

Report D

efectBusiness Blueprint (Draft)

1Build initial Test Cases Structure

2

Business Blueprint (Final) 3

Finalize Test Case Structure4

Customizing

Development

UI Design

5

Implement Test Cases6

Test Execution7

Document Results8

Test Data Analysis10

Display Analysis 12

Design Handover:• System Type• Business Blueprint• Transaction• General Doc• Project Doc• Status• Keywords• Graphics• Blueprint Lock• Requirements

Build Handover:• Logical Component• Status• Requirements• Config Lock (tbd)• Lock Requirement Tab

Execute Handover:• Link to Requirement• Execution Results to


Test Status9

11

13

Status

Status

Status

Close Implementation Project15

Create Implementation Project0

Close Project Cycle/ Release14

Create Testing Project 0

Link

Status

Queries

The documentation in HQC is based on the information provided by SAP Solution Manager. For each business structure node, a folder is created in HQC. Additional information on each business structure node is handled as a folder attribute in

HQC. Those attributes are stored in the same way as in SAP Solution Manager (e.g. Tabs). Content of SAP Solution Manager tabs are displayed via a link in HQC. Test requirements on business level will be assigned on the new tab “Requirements” in SAP

Solution Manager. SAP Solution Manager test requirements are replicated 1:1 in HP Quality Center (push and

pull updates). Manual test cases from SSM content are treated like a requirement and transferred to HP

Quality Center as a requirement. HQC requirements are available via a link from SAP Solution Manager requirement. Definitions: • Test requirement in SAP Solution Manager = description of test content on business level • Test case in HP Quality Center = description of test content on technical level

HP Quality Center is Master System for calculation of test execution result status.

© SAP AG E2E200 9-649

Preconfigured Dashboard UI and API for basic data are provided by HQC and displayed in SAP Solution Manager.

Ad-hoc analysis and reporting of test status and test status values are possible, by request through SAP Solution Manager (based on transferred time stamp and requirement/ or business structure from SAP Solution Manager to HQC)

For detailed analysis, its possible to access the test data via a link in HQC. It is possible to maintain BI reporting based on HQC standard values in SAP Solution

Manager.

© SAP AG E2E200 9-651

© SAP AG 2007

Testing Approach

Manual Testing:After the creation of test case descriptions, testers perform the actual testing manually.The result of each test case is recorded manually.No test automation tools are being used.Test management tools can be deployed for test administration and test organization.

Automated Testing:After the creation of test case descriptions, the actual testing is performed by automated test tools.After the test, the result of each test case is recorded automatically by the test tool.

Clear and detailed test run recordsTest cases can be reused for later purposes.(e.g., Support Packages) Regression TestingMethodical approach to reduce costs and safeguardthe software lifecycle process.

© SAP AG E2E200 9-652

© SAP AG 2007

What can be tested with eCATT

DatabaseTable operations

DataTable

Cust.Table

SAP GUI for Windows and Java

SAP GUI for HTML / external apps.

?

Web

AS

Web Dynpro viaPresentation Server

eCATTServerBusiness Logic

ClientGUI

eCATT can only test WebDynpro via the Presentation Server and SAP GUI for Windows and Java.

If SAP GUI for HTML or external applications must be tested, 3rd party test tools must be used. An interface exists: 3rd party tools can be encapsulated into an eCATT. That means eCATT calls the 3rd party tool and receives the results after the test run.

eCATT can read tables from the database and it can simulate new customizing settings

© SAP AG E2E200 9-653

© SAP AG 2007

Integration of External Tools into eCATT

eCATT is not intended to be able to test any application running on any platform

Instead, it aims to be the best tool available for testing in proprietary SAP environments such as

SAPGUI for Windows and SAPGUI for JavaThe SAP application serverThe SAP database server

To enable testing of external applications from within the eCATT environment, a certifiable interface allows third-party tools to integrate their solutions with eCATT

The following products are currently certified against the BC-ECATT interface: • Compuware TestPartner (5.1 or higher) • Mercury QuickTest Professional (6.5 or higher with SAP Add-on) • Segue Software SilkPerformer (7.2 or higher)

© SAP AG E2E200 9-654

© SAP AG 2007

Requirements for eCATT

Support Package LevelEach system where you want to test must have at least the following support package level:

4.6C: Support Package 324.6D: Support Package 216.10: Support Package 176.20: Support Package 03

Client SettingsFor each client in which you want to test, you must ensure that the CATT/eCATT flag is set to allow tests to run.

GUI ScriptingIn order to use the new GUI Scripting functions, the following settings have to be made:

Profile parameter sapgui/user_scripting must be set to TRUESAP GUI must be Version 6.20 with patch level =>18 and GUI Scripting installed

Before you can start testing, you must prepare your various systems. Each of your target systems must have the appropriate support package level as shown above.

For each client in which you want to test, you must ensure that eCATT is allowed. To do this, start transaction SCC4, pick the relevant client and ensure that the Restrictions when starting CATT and eCATT option is set to CATT and eCATT allowed.

To use the SAPGUI command (see unit 6), you must ensure that GUI Scripting is active in the central test system and in any target systems that you may require. To do this, start transaction RZ11 in the relevant system, enter profile parameter sapgui/user_scripting and choose Display. If the current value is FALSE, change it to TRUE. You must log off and back on again for the change to take effect.

© SAP AG E2E200 9-655

© SAP AG 2007

An automated test script with eCATT

Testinstructions Log Archive

Test configuration

Nr 400

Nr 500

Nr 620

System data

Test data

A finished test case: the test case that a user will see in his work-list in the SAP Test Workbench consists of: • A set of instructions that describe the test case • One or more sets of data with which the test case will be executed • A description of the system landscape in which the test is to be performed

The result of each test run is a log. The log contains detailed information about the test environment (system – including technical platform information and release, user, time and date) and the commands that were executed during the test. You can also see the data that was fed into the test case and the results that it returned. Logs can be either archived or deleted using periodic background jobs.

© SAP AG E2E200 9-656

© SAP AG 2007

Script Language Elements

Inline-ABAP Customizing

Applications

Conditions

ChecksLo

ops

Calculations

Reading TableValues

The main purpose of eCATT is to record applications. However it allows you to record and replay applications, perform checks, and use various

common programming control structures. You can read table values, include ABAP coding and simulate customizing settings.

© SAP AG E2E200 9-657

© SAP AG 2007

Commands for Recording Applications

Applications

FUNCalls a Function

Module

TCDAllows you to record

and replay SAP Transactions

SAPGUIAllows you

to record sequencesof screens containing

controls

An interface allows youto integrate test tools

from third-party vendors

with SAP eCATT

WebDynproAllows you

to record webdynpro-based transactions

There are five different ways of testing applications. Each of them is appropriate for a particular kind of application that you might want to test.

It is important to remember that no single way is suitable for testing everything. For this reason, you should always take care to pick the correct driver before you start to record your script.

© SAP AG E2E200 9-658

© SAP AG 2007

Pattern Function

The Pattern function is similar to the statement pattern in the ABAP Editor. It allows you to build individual eCATT commands.

The pattern function allows you to create eCATT commands quickly and easily. A command consists of: • The command keyword • Argument (the target object, for example, the function module you want to call or the

transaction you want to record) • Interface (parameters that need to be passed will be generated automatically) • Target system

You can use any system that is defined in the current system data container. If there is no system data container attached to the script, you can only execute the command locally.

© SAP AG E2E200 9-659

© SAP AG 2007

Test 3Test 2Test 1

Test Automation – Effort Calculation

25

2,5

14 1414

Automated tests

Manual tests

Initial effort for development

of eCATT scripts

Test effort(people days)

2,5

Break-Even

Regular Software Maintenance / Transports(Support Packages, Customer Coding)

Cumulated effort

Adjustments and execution of eCATT scripts

In this example the test effort after regular software mainenance was 14 FTEs for manual testing of the core business processes.

With eCATT the regular test effort was only 2,5 FTEs for the adjustment and execution of the eCATTs. The break-even was reached at the second test cycle.

The diagram shows that the creation of scripts has a high initial effort but with continued usage a break-even point is reached.

© SAP AG E2E200 9-660

© SAP AG 2007

Test Management Optimization – Project Timeline

Research

Q4/2004 Q1/2005 Q2/2005 Q3/2005 Q4/2005 2006

Phase 2Automated Regression Test

Core Business Processes (class 1)

Test FrameWork

Pilot

TMO

Test Framework(manual test cases)

Phase 1

Phase 2

Phase 1 Core Business Processes (class 1, 2)

Manual Regression Test

Test AutomationFramework, eCatt

eCatt Pilot

Test Automation

In this example, a customer started a test management optimization project in 2004. In phase 1, all test case descriptions for class 1 and 2 projects were reviewed, updated into a

predefined template and loaded into the Test Organizer of SAP Solution Manager. This project phase lasted about six months.

In phase 2, the manual test cases for class 1 projects were partly automated by eCATT. This project phase ran for about 9 months.

© SAP AG E2E200 9-663

© SAP AG 2007

SAP Code Inspector

This is a tool for checking static ABAP coding and DDIC objects (generally: TADIR objects).

Aspects of checks are:Performance, Security, Reliability, and Statistical Information

Checks are performed on single objects or Object Sets(programs, function modules, classes, interfaces, DDIC-objects).

A Check Variant can be made up of one or several single checks.

A Check Variant and one object/Object Set can be combined into an Inspection.

The Code Inspector tests single objects or object sets (programs, function groups, classes, interfaces, Dictionary objects) for performance, security, serviceability, error proneness, and statistical information.

You can call the Code Inspector for the relevant single objects directly from the ABAP Editor (SE38), the Function Builder (SE37), or the Class Builder (SE24) (Object->Check->Code Inspector). The system then checks using a default check variant.

© SAP AG E2E200 9-664

© SAP AG 2007

Run Inspection before and after project import

Object sets, check variants, and inspections are created using transaction SCI. Object Sets and Check Variants (that is, combinations of single checks to which you can assign parameters) are managed independently of one another. An Inspection connects each check variant with an object set.

© SAP AG E2E200 9-665

© SAP AG 2007

Select Syntax Check Generation

Individual checks are assigned to different check categories. The following list shows examples of check categories and individual checks. • General checks contain formatting elements, such as listing table names from SELECT

statements. • Performance checks contain checks for performance and for resource use, such as: • Analysis of the WHERE condition for SELECT / UPDATE and DELETE • SELECT statements that read past the table buffer • Low-performing accesses to internal tables • Security checks contain checks for critical statements, cross-client queries, inadequate

authority checks. • Syntax check / generation contains ABAP syntax check, an enhanced program check, and

generation: • Programming conventions contain checks for name conventions. • Search functions contain searches in ABAP coding for tokens (words) and statements.

© SAP AG E2E200 9-666

© SAP AG 2007

Create Object set – save object set with your search key

Using sets of objects, you can group several single objects together for an inspection. Sets of objects include, for example, programs, function groups, classes, or DDIC objects. In general, any Repository objects can be included in a set of objects.

In this example all objects with original system DEV were selected.

© SAP AG E2E200 9-667

© SAP AG 2007

Run Inspection

During an inspection, individual objects or sets of objects are checked to see if certain programming guidelines have been adhered to. The result of an inspection run is a list of the individual checks made with errors, warnings, or information messages.

© SAP AG E2E200 9-668

© SAP AG 2007

Results of Inspection

HTML Document

An inspection returns a Check Result, from which you can derive another object set.

© SAP AG E2E200 9-670

© SAP AG 2007

Goals of a Volume Test

Ideally, ALL possible situations where critical data volumes might come up the system performance should be tested:

Large data volume (background jobs) as defined by business time-windowsHeavy dialog activity Many concurrent users (possibly same/similar transactions)

Which business processes?Load start pageLogonSearch for …View ResultsLogoff

How many executions per time interval?Extraordinary Situations:

Recovery scenarios What happens in case of (possibly enormous) data back-logs after system(s) have not been availableChristmas / seasonal business activities in addition to “average”business.

Large data volume (background jobs) as defined by business time-windows Heavy dialog activity many concurrent users (possibly same/similar transactions),

expensive jobs started in dialog task which must be finished in a given time-frame and/or are impacting the performance

Recovery scenarios What happens in case of (possibly enormous) data back-logs after one (or several) systems have not been available for a certain while (HW failure, standard maintenance, software issues that require a system re-start, LiveCache breaks down recovery, data upload heavily requires system resources)

Additional business requirements what happens in case of, e.g., Christmas / seasonal business activities which challenge the available resources stronger than “average” business?

These business peaks may lead to a backlog which has to be processed later and does require additional time-windows.

© SAP AG E2E200 9-671

© SAP AG 2007

What should be Monitored?

SAP System Checks:Single Statistical RecordsR/3 work process overviewResponse times, CPU times, database times and number of executions of the programs and transactions that implement the business process steps involved in a test scenario Utilization of SAP shared buffers and SAP memoryNumber of active usersError messages and warnings

Single Statistical Records STAD R/3 work process overview SM66 Response times, CPU times, database times and number of executions of the programs and

transactions that implement the business process steps involved in a test scenario ST03 Utilization of SAP shared buffers and SAP memory ST02 Number of active users SM04 Error messages and warnings ST22, SM21

© SAP AG E2E200 9-672

© SAP AG 2007

Performance Analysis Tool /SDF/MON

Performance Analysis Tool /SDF/MON has been developed for expert analysis of system performance in SAP R/3 systems.

This tool collects information, from different sources, about CPU Utilization, Memory Management, Database, Work Process, Workload, STAD, RFC, etc and stores this information in database for further usage. This information is collected for a predefined period of time with a predefined resolution (e.g. each x seconds).

In comparison with standard performance analysis transactions like ST06, ST02, ST05, STAD etc., the main benefit of /SDF/MON tool is that all collected information for performance analysis is linked automatically to the time stamps, and is available from one single screen (it is not necessary to switch between different screens and compare time stamps manually).

The tool is available with ST-PI 2005.1, SP3.

© SAP AG E2E200 9-673

© SAP AG 2007

What Should be Monitored?

Operating System Checks:CPU utilizationMemory utilizationDisk statisticsNetwork Adapters

Database Checks:Buffer QualityLock wait situationsShared SQL AreaLatches

These checks have to be performed on the different platforms. Each operating system and database provides different tools and procedures to monitor the

load.

© SAP AG E2E200 9-674

© SAP AG 2007

How to Generate the Load?

The load can be produced manually by the users.Users have to perform dialog steps during the load test

Alternatively, you can use load injection tools, like SAP Loadrunner by Mercury. In the SAP environment the following types of virtual users are important:

ERP/CRM: It connects via the SAPGUI Scripting language to a SAP GUIE-Business: It connects via the http / https protocol to a SAP application (e.g. Enterprise Portal)

The V-user of type ERP/CRM instances a SAPGUI on the frontend where it is started. Due to the resources on the frontend, the number of V-users per frontend is limited to about 30.

The V-user of type E-Business connects directly to a proxy server. With this V-user type, more than 500 connections per frontend are possible.

© SAP AG E2E200 9-675

© SAP AG 2007

Load Generation by External Tools

Load generator

Backend(e.g. ERP)

Server (e.g. EP)

Database

Controller

• Controls the test

• Collects monitoringdata

Operating System

Monitoring J2EE

Monitoring CCMS

Monitoring DB

Monitoring OS

The first step in the execution of automated load tests is to record scripts. Then, the scripts can run in parallel.

The number of parallel executions is controlled by a controller. The controller also collects monitoring data from the different systems and platforms which

are involved in the test. During the GoingLive Check Optimization session for Enterprise Portal a load generator

needs to be installed at the customer side. The controller is installed at SAP and operated by the watcher. The preparational steps are explained in SAP note 807951.

© SAP AG E2E200 9-676

© SAP AG 2007

SAP Loadrunner by Mercury

This is a screenshot of SAP Loadrunner by Mercury. In the box Scenario Groups, you see two different test scripts which run in parallel. In this example, the script “test1” is executed 30 times in parallel. The script empty did not start yet. You can start and stop scripts or add virtual users with the buttons next to the Scenario Groups.

In the lower part of the screenshot, certain monitoring data is collected. The graphs show the number of virtual users (V-users), the hits per second, the transaction response time and the Windows resources.

After the test run, the monitoring data is available for further analysis.

© SAP AG E2E200 9-678

© SAP AG 2007

Setting up a Test Landscape

Create a relevant test landscape by:Client CopySystem CopyManual Creation of Test DataSAP Test Data Migration Server

BAKBB-Copy of B

/MYSAP/

SAP

SDTUDelivery

PRDProduction B

TQAQuality Asst.

ZTDV

TDVDevelopment

ZTDV

© SAP AG E2E200 9-679

© SAP AG 2007

System Copy Procedure

Advantages:Identical copy of the whole system, including repository objects, client independent and client dependent dataNo downtime of production system is needed, as a backup can be usedSplit Mirror Technology supports fast system copies

Disadvantages:If the production system is very large, the test systems also get very largeSensitive data is copied into the test systemSettings need to be readjusted after the system copyTransports need to be re-imported into the test systemSame client structure must be used in test system as in production systemVersion history is overwritten (in development systems)

© SAP AG E2E200 9-680

© SAP AG 2007

System Copy Procedure with a Backup

PRD QAS

1) Backup

2) Re-Import missing

transports

1) Set up QAS with a current backup of PRD.

2) Re-Import all transports which are in transition (have already been imported into QAS but not yet in PRD) into QAS.

All transports which were already imported in QAS, but are not yet in the current backup of PRD must be re-imported after the system copy.

Sometimes customers use a special master backup for the setup of test systems. One reason for using a master backup can be that it contains an appropriate amount of test data. Often, the production system is so big that it cannot be copied any more.

The master backup is a baseline for the software configuration. All changes since the time of the backup must be re-imported into the new test system.

© SAP AG E2E200 9-681

© SAP AG 2007

Determine the Delta: Compare the Import History

Use the Import History to determine the transports which were imported into QAS, but not in PRD. These transports must be re-imported after the system copy.

STMS Overview Imports Select a system Go to Import History

Extract the import history in QAS before the system copy and after the system copy. The missing transports must be re-imported.

© SAP AG E2E200 9-682

© SAP AG 2007

Change Tracking in SAP Solution Manager

SAP Solution Manager provides a tracking function, which automatically determines the delta transports.

© SAP AG E2E200 9-683

© SAP AG 2007

Usage of Virtual Systems

DEV QAS PRD

Virtual System VRP

Virtual systems can be used as collectors for transport requests.

When a transport is imported into QAS, it is automatically added to the VRP Buffer.

Recommendation: Keep one buffer for each project / release / Go-Live

When a transport is imported into QAS, it is automatically added to the VRP Buffer. Therefore, the import buffer of the virtual system VRP contains the complete import history of QAS.

The buffer of VRP can be attached to QAS after a system refresh. Then, the missing transports can be re-imported.

The usage of the virtual buffer avoids the work of adding many transport requests to the QAS buffer by using the “tp addtobuffer” command.

We recommend to save one buffer for each project / release / Go-Live (project buffer). Starting from a baseline, you can then re-build the software configuration after each Go-Live in your test systems.

© SAP AG E2E200 9-684

© SAP AG 2007

Usage of Virtual Systems as Project Piece List

DEV QAS PRD

Virtual System VRP

CIC_3.01_15_03_2007

Maintcycle_30_03_2007

CIC_3.02_15_04_2007

Software Library

Recommendation: Copy the buffer foreach project / release / GoLive

Virtual systems can also be used as a piecelist for all transports that belong to a certain project. For that purpose the virtual system is added behind the production system and collects all

transports that are imported into production. If a test system needs to be rebuilt you can import the individual project buffers in the right

sequence.

© SAP AG E2E200 9-686

© SAP AG 2007

TDMS

Productive system

Non-productive systemsTDMS:

Provide representative application data (extract) from a productive system to non-productive systems

Focus: Refresh of an existing system

Selection of data from production system by different scenarios like:

Master dataCompany code“time slice”

SAP Test Data Migration Server

With SAP TDMS you can: • Reduce data volume in test systems • Simulate production environment by using real business data • Preserve consistent business processes within the target system • Reduce post-processing work by keeping administrative data (objects) in the target system

unchanged (interfaces, users, authorizations, etc.) • Perform selective refresh of individual clients in target system (esp. in multi-client

systems) • Scramble sensitive data according to your needs

© SAP AG E2E200 9-687

© SAP AG 2007

Available Scenarios

Choose the set of data to be extracted from your production environment:

MD/C-Scenario (Master and config. data)Only master and configuration data No transaction data

TIM-Scenario (Time-based)All master and configuration data A reduced set of transaction data (based on selected FROM DATE)

TDMS also copy Customizing data. This means all transports thathave already been imported into the target system, but are missingin the source system must be re-imported.

TDMS also copy Customizing data. This means all transports that have already been imported into the target system but are missing in the source system must be re-imported.

© SAP AG E2E200 9-688

© SAP AG 2007

Application of Different Reduction Scenarios

Development System:Additional test client in development system – no interference with actual development clientMaster Data & Configuration(Creation of transaction data by testers)Time-Based reduction

Alternative 1: with e.g. two monthsAlternative 2: with only very few transaction data, e.g. 1 week

Test Environment:Depending on test purposes, the amount of test data in the system can be varied.

Q/A system with 60% of production dataTest system with 30% of production dataTraining system with 10% of production data

The amount of test data that is copied can be selected flexibly.

© SAP AG E2E200 9-689

© SAP AG 2007

SAP TDMS – Reduction of Data Volume

Assumption:

80 - 90% of the production data is stored in 10 - 20% of client-dependent tables

Data volume reduction:

In order to reduce the overall volume, only some tables need to be reduced

All other tables (master and configuration data) are migrated entirely

Customer-individual tables are transferred entirely or can be reduced via e.g. time criteria

Some tables are excluded from transfer by default:

E.g. change documents, user tables, etc. (customizable)* Estimate based on project experience

7% Config. Data *

3 % Admin- Data*

80% Transaction Data *

10% Master Data *

Client DB

© SAP AG E2E200 9-690

© SAP AG 2007

Technology - Architecture

Sender System SAP TDMS Receiver System

Fast, optimized data transfer:Proven, high-speed data extraction technology (Migration Workbench)Table-wise data migration via RFC (Remote Function Call) connections

The Test Data Migration Server is built on top of the Migration Workbench which is a proven and stable tool.

© SAP AG E2E200 9-691

© SAP AG 2007

Facts and Figures

System Recommendation:SAP WebAS 6.20, 6.40 or 7.00Shipped as Extension of SAP Solution Manager 4.0Minimum 4 CPU, 4 GB RAM, 20 GB HD

Supported Releases:SAP R/3 4.6C SAP R/3 4.7mySAP ERP 2004 (ECC 5.0)mySAP ERP 2005 (ECC 6.0)

Pricing:Price is dependent on size of production DBLicense covers one production system and n non-production systems

Knowledge Transfer/Training:TZTDM3 (offered by SAP Education)

© SAP AG E2E200 9-692

© SAP AG 2007

Solution Support Enablement Package (SEP) at a Glance

Packaged Tools:BMC AppSight for Windows/.NetSAP Test Data Migration ServerCA Wily IntroscopeSAP Custom Development

Optimization PackageSAP Reverse Business EngineerSAP Best Practices for

Operations

The Solution Support Enablement Package provides a suite of proven tools that enable your IT support organization to deliver

best-in-class support for your SAP solution.

Find more information at http://service.sap.com/sep

In E2E Change Control, the following Solution Support Enablement Package tools are of special interest:

SAP Custom Development Optimization Package: • Change Impact Analysis during testing and import of support packages or upgrades

SAP Client Migration Server: • Customizing and repository compare of two systems (homogeneity of the system

landscape) SAP Test Data Migration Server: • Set up test systems with current test data

© SAP AG E2E200 9-694

© SAP AG 2007

Guideline for Test Case Selection

What should be tested?Minimum: Core Business Processes that are critical for the business. These test cases must be selected by the business process owners through ABC analysisTest cases that showed problems in previous test runsAreas which are affected by the new changesMost frequent transactions according to ST03 transaction profile

© SAP AG E2E200 9-695

© SAP AG 2007

Categorization and Evaluation of Business Processes

20% of efforts

80% of coverage

20% of coverage

80% of efforts

Selection of Business Processes for automation should be done taking several different aspects in mind

20% of efforts

80% of coverage

Example of possible Business Processes prioritization in terms of complexity and impact for business

Low High VeryHigh

Impact

Standard

Complex

VeryComplex

Complexity

11

2

23

3

3

Prio 2

Prio 1

Prio 31

2

The Business Processes chosen to be involved into the test concept must be divided into several company-wide categories (preferably three or four) in accordance with their priority and availability requirements. To each category a description should be provided which explains clearly what range of Business Process priority and availability requirements is covered by this certain category.

You should define criteria which determine whether a test of a Business Process will be automated or not. Generally speaking, the business processes which are first candidates to have automated test cases are the processes which: • are most critical for the company – you will have a possibility to test them even in times

of very limited time and resources availability. • runs over several systems and includes several interfaces – you will have more guarantee

that no step in a process will be overseen or ignored and that all interfaces, which are often considered as a “socket in the wall”, are tested and running properly

• are being tested most often – a lot of resources will be saved, ROI is guaranteed. Please also note that automatic testing is no magic formula for a balanced test management

situation. It would be a wrong decision to try to automate all the tests performed in the company as some of them can only be automated and maintained with a significant effort and which exceeds the efforts of performing them as manual tests

© SAP AG E2E200 9-696

© SAP AG 2007

ST03 Transaction Profile

You can go to the transaction profile in ST03. Select the total workload for the last month. In the analysis view, select the transaction profile.

Sort the list by number of dialog steps. This gives you the most frequently used transactions and reports.

You can also sort the list by total response times. The result will be the transactions and reports that cause most load in the system.

© SAP AG E2E200 9-697

© SAP AG 2007

Key Aspects of Successful Test Strategy

Centralized test coordinationDefinition of the test environmentManagement commitment and commitment for the test resourcesCategorization of the business processes in accordance with their priority and availability requirementsPlanning of organizational and methodological actions to ensure the completeness of test casesEvaluation of the business processes and selection those of themyou want to create automated test cases for (manual <> automated)Usage of dedicated tools for test administration, execution and monitoring

© SAP AG E2E200 9-698

© SAP AG 2007

Test Management: Unit Summary

You should now be able to:Explain different types of tests and test strategies

Describe the features of the Test Workbench and eCATT

Understand the benefits of SAP Solution Manager and how SAP Solution Manager is integrated with the HP Quality Center

Use the SAP Code Inspector to perform automated syntax checks

Describe how to prepare test systems by performing system copies or by using the SAP Test Data Migration Server

Set guideline for how to select test cases

© SAP AG E2E200 9-699

Exercises

Unit: Test Management

At the conclusion of this exercise, you will be able to: • Organize a test project with the SAP Solution Manager • Execute the test cases and protocol the results


9-1 Create a new test plan.

9-1-1 Create a new test plan with the name E2ECC_## Integration Test Cylce 1 and assign it to your solution E2ECC_##.

9-1-2 Assign all test cases which are available in your solution to the test plan and generate the test plan. How many test cases do exist?

9-2 Create a new test package. 9-2-1 Create a new test package with the name E2ECC_## Test Package 9-2-2 Select all available testcases and generate the test package. 9-2-3 Assign the test package to your own user-ID and to your neighbor.

9-3 Now you are acting as a tester. 9-3-1 What is the transaction for executing the tests?

Answer: _________________________________________________________ Call that transaction. Which test packages are in your worklist? Navigate into the test package E2ECC_## Test Package.

9-3-2 Test the business process step Create Sales Order in ECC. a) Read the manual test case description. b) Logon to the system TT5:600 and execute the test case according to the description. Does the test deliver the expected result?

9-3-3 Test the business process step Create Sales Order in CRM. This is an

eCATT configuration. What is the total runtime for the test case?

© SAP AG E2E200 9-701

What was the runtime for the different transaction steps? Answer: _________________________________________________________ How is the result of the test run rated? Answer: _________________________________________________________

9-4 Now you are the test manager. Perform a status analysis of your test plan. 9-4-1 Go the transaction STWB_INFO and select your project and your test

plan. Do also mark the checkbox Update Test Plans automatically. 9-4-2 How many test cases have the following status?

Errors: ____________ % No Result: _________ % OK: ______________ %

9-4-3 Check in detail which test cases have errors.

© SAP AG E2E200 9-702

Solutions

Unit: Test Management

9-1 Create a new test plan. 9-1-1 Create a new test plan with the name E2ECC_## Integration Test Cylce 1

and assign it to your solution E2ECC_##. Goto transaction STWB_2 and press the button to create a new test plan

( ). In the next screen select your project, enter the title E2ECC_## Integration Test Cycle 1.

9-1-2 Assign all test cases which are available in your solution to the test plan

and generate the test plan. How many test cases do exist? In the screen Test Plan Create for Solution E2ECC_## click on the button

Expand All to expand the Test Plan Structure. Now you see all test cases and transactions that are available. Select all test cases and transactions and click on the button Generate Test Plan . Save as local object.

9-2 Create a new test package. 9-2-1 Create a new test package with the name E2ECC_## Test Package

In the screen Test Organizer: Test Plan Management select your test plan and click on the button Test Package Management . screen Test Organizer: Test Package Management click on the button Create Test Package .

9-2-2 Select all available testcases and generate the test package.

© SAP AG E2E200 9-703

In the Create Test Package screen expand the complete structure and select all test cases. Then click on the button Generate. Enter the name of the test package. Save as local object.

9-2-3 Assign the test package to your own user-ID and to your neighbor.

In the screen Test Package Management select your test package and click on the button Assign Testers . Enter your own user-ID and the user-ID of your neighbor.

9-3 Now you are acting as a tester. 9-3-1 What is the transaction for executing the tests? Call that transaction.

Which test packages are in your worklist? Navigate into the test package E2ECC_## Test Package. Goto transaction STWB_WORK. There should be at least two test packages assigned to your worklist: Your own test package and the one of your neighbour. Navigate into your own test package with a double click. Select the business process Sales Order Management and expand it.

9-3-2 Test the business process step Create Sales Order in ECC. a) Read the manual test case description. Click on the test case description for the business process step Create Sales Order in ECC.

b) Logon to the system TT5:600 and execute the test case according to the description. Does the test deliver the expected result?

© SAP AG E2E200 9-704

The report ZZ_CHANGE_CONTROL_TEST in TT5 gives an error message when you press “No”. Record the test result by clicking on the traffic light for the status. Enter the status Errors/Retest required and save your input.

9-3-3 Test the business process step Create Sales Order in CRM. This is an

eCATT configuration. What is the total runtime for the test case? What was the runtime for the different transaction steps? How is the result of the test run rated? Click on the button to run the automated test case ( ). Observe the different screens that are executed.

The total runtime and the runtime for the different transaction steps can be seen in the eCATT Log Display.

The result of the test run is rated automatically.

9-4 Now you are the test manager. Perform a status analysis of your test plan. 9-4-1 Go the transaction STWB_INFO and select your project and your test

plan. Do also mark the checkbox Update Test Plans automatically.

© SAP AG E2E200 9-706

9-4-2 How many test cases have the following status? Errors: _________% No Result: _________ % OK: __________ % This information is available on the screen Status Info System.

9-4-3 Check in detail which test cases have errors.

Click on the button Status overview to get a detailed list of all test cases with their status.

© SAP AG E2E200 10-708

© SAP AG 2007

Content:

Change Diagnostics

Change Deployment



Test Management

Solution Quality Reporting

IT Reporting for Change Control : Unit Content

© SAP AG E2E200 10-709

© SAP AG 2007

IT Reporting for Change Control: Unit Objectives


Describe KPIs which are relevant for IT Reporting for Change Control

Know data sources to build up IT Reporting for Change Control

© SAP AG E2E200 10-710

© SAP AG 2007


Test Management

MaintenanceChange Request

Management

Deployment

Change Diagnostics

Solution Quality

Change Diagnostics supports customers in identifying, controlling, maintaining and verifying the versions of configurations of the system landscape components to provide a heterogeneous system landscape.

Change Deployment aims to give a holistic view of an application change in a solution and should ensure that all involved components of an application change are tested and released together.

Change Request Management is the efficient and punctual implementation of SAP software changes, with minimal risks, using standardized methods and procedures.

Maintenance supports the customer in planning and downloading the available SAP software patches and updates for his complete solution landscape.

Test Management supports the customer in planning, preparing, executing and evaluating test cycles. Testing is used to identify the characteristics of a software solution and point out the difference between the actual and required states.

© SAP AG E2E200 10-711

© SAP AG 2007



Lesson 2: Change Deployment

Lesson 3: Change Request Management

Lesson 4: Maintenance Management

Lesson 5: Test Management

Lesson 1: Change Diagnostics

Lesson 6: Solution Quality Reporting

© SAP AG E2E200 10-712

© SAP AG 2007

Change Diagnostics KPIs for IT Reporting

Goal:

Change Diagnostics supports customers in identifying, controlling, maintaining and verifying the versions of configurations of the system landscape components, to provide a heterogeneous system landscape.

KPIs:Number of changes in the parameter configuration per time unitInconsistencies in the parameter configuration within the transport landscape and within the productive environmentCompleteness of landscape description in SAP Solution Manager

© SAP AG E2E200 10-713

© SAP AG 2007

Compare Multiple Instances

Missingvalue

Additionalvalue

Unchanged value

Different value

Additional value

Missing value

The function “Compare Multiple Instances” reduces the effort spent on comparing multiple J2EE Nodes and complex J2EE landscapes in the background.

You can compare different nodes on the same host, or nodes on different instances and different hosts.

A history of changes is provided for each configuration parameter (based on daily snapshots). In addition, it is possible to display the configuration for a given point in time.

It enables the organization to standardize the solution configuration.

The use case “Compare Multiple Instances” is very useful to: • compare different instances among different hosts (clustered environment) • compare different instances from different landscapes (eg: PROD vs, QAS, DEV, TEST)

Procedure: • Navigate to Compare Multiple Instances ->Trigger compare tab • Check two or more instances to compare • Select one instance as the main instance. This will be used as reference. All other instances

are compared with the main instance. • Trigger the compare (takes a few second until the icon changes to green).

© SAP AG E2E200 10-714

• Click the Display button and the “Compare Results” are displayed in the navigation window.

• The parameter changes (different value, missing value, unchanged value and additional value ) are marked with different icons.

© SAP AG E2E200 10-715

© SAP AG 2007

Number of Parameter Changes

The E2E Change Analysis Tool shows the number of parameter changes in a certain time interval.

You can see the total number of changes and the number of changes per day. It is important to see if the configuration parameters were only changed at certain maintenance

windows, or, if they were changed continuously.

© SAP AG E2E200 10-717

© SAP AG 2007

Change Deployment KPIs for IT Reporting

Goal:

Change Deployment aims to give a holistic view of an applicationchange in a solution and should ensure that all involved components of an application change are tested and released together.

KPIs:Number of transports in the system per time unitNumber of errors during the transports per time unitModification level of the systemsConsistency of the transport landscape

© SAP AG E2E200 10-718

© SAP AG 2007

Transports into Production - Overview

PRD

QAS

DEV

In this example, the customer delivers production in release cycles. Major Go-Lives have been performed on the following dates: 18/11/2005, 10/12/2005, 07/02/2006 and 18/03/2006.

According to the customers strategy, there is one release delivery to production per quarter. However, in this example there have been an additional deliveries.

The relevant data for this graphic can be derived from the Import History.

© SAP AG E2E200 10-719

© SAP AG 2007

00 02 04 06 08 10 12 14 16 18 20 22

Tota

l DB

Tim

e [la

st m

onth

]

0

100

200

300

400

500

00 02 04 06 08 10 12 14 16 18 20 22

Tran

spor

ts [l

ast s

ix m

onth

]Workload per day, compared with number of transport requests.

Quality Risk

Technical Analysis of the Transport Statistics show the risks to the current Change Schedule, due to many transport during high workload.

Transport into Production During the Day

This diagram shows the time distribution of the imports into production. Some transports take place between 09:00 and 12:00 o‘clock at the time of the highest workload in the system.

© SAP AG E2E200 10-720

© SAP AG 2007

Source Systems of Transport Requests in Production

27.02.0601.01.05161DE1

27.04.0601.11.0542QAS

28.04.0601.11.0558PRD

23.03.0601.12.0510DE2

11.04.0610.11.051.453DEV

Date of last import

Date of first import

Number of transports

Source Systems

Many transport requests are cross transports from the system DE1, which is outside the system landscape. Some transport requests were created in the Quality Assurance system, or even in the production system.

© SAP AG E2E200 10-721

© SAP AG 2007

2.558Modified Objects

16.025Customer Objects

14.737Customizing Requests since System Installation

17.125Workbench Requests since System Installation

ValueIndicator

System Modification Level

The number of customer objects and modified objects in this example is very high. A high number of modified objects and/or customer objects causes a lot of effort for

adjustment during upgrade and support package projects. Therefore, it increases the Total Costs of Operations.

The number of Workbench and Customizing requests is in balance. If the number of workbench requests is much higher that the number of customizing requests, it shows that no standard functionality is used but most functionality is developed customer specific.

The number of transport requests can be derived from the import history. The modified objects can be seen in the Modification Browser (SE95). The customer objects can be seen in the Transport Organizer Tools (SE03) Objects in Customer namespace.

© SAP AG E2E200 10-722

© SAP AG 2007

Modified Objects by Application Component

522Sum

23Technical Application SupportCA-GTF-TS

24SAP Business WorkflowBC-BMT-WFM

29Material MaintenanceSD-MD-MM

42Basic FunctionsSD-FT-PRO

48LocalizationFI-LOC

52SalesSD-SLS

73Financial AccountingFI

80Data CollectionLO-LIS-DC

151ConditionsSD-MD-CM

No. of objectsDescriptionComponent

This table shows an overview of modified objects, grouped by application component. Most modifications are in the areas SD -Conditions and LO – Data Collection. These areas need special attendance during support package imports or upgrades.

© SAP AG E2E200 10-723

© SAP AG 2007

Customer Objects by Development Class

Other Dev Classes

Business Warehouse developments

Temporary Objects (never transported!)

Basis Regional

dummyDevelopment FI

Development MMBasis Global

Development SDEDI

Description

8262Sum1327Other

139Z_BW

162YRS1320$TMP

358ZBC

385YPP459YFI

854YMM1336YBC

1377YSD1545YEDI

SumDevelopment Class

This table gives an overview of customer objects, grouped by development class. If customer objects are using SAP standard objects, they are also affected by support package imports and upgrades.

© SAP AG E2E200 10-724

© SAP AG 2007

Most Frequently Changed Objects

64Z_BWLIMU REPS MYFDCF08

66YRS1LIMU REPS MYFDCF07

66$TMPLIMU SHI3 YSSA-MENU

68ZBCLIMU SHI6 YSSA-MENU

68YPPLIMU REPS MYFDCTOP

82YFILIMU REPS SAPMYFDC

90YMMLIMU REPS MYFDCF03

98YBCLIMU REPS MYFDCF04

104YSDLIMU REPS MYFDCF01

106YEDILIMU REPS MYFDCF02

No. of ChangesDevelopment ClassObject

These objects were changed very often. In these cases, the design might have been inadequate.

© SAP AG E2E200 10-725

© SAP AG 2007

Errors During Import into Production - Last Six Months

00016

30012

920008

No of ErrorsReturn Code

There were 92 transport errors with return code 0008 and 3 with return code 0012, during imports in production in the last six months. This is a high number. It should be close to zero!

The import process should be monitored in the quality assurance system. If there are transport errors, they should be corrected before the import into production. The correction transport should be imported together with the original transport that caused the error. The relevant data for this graphic can be derived from the Import History.

© SAP AG E2E200 10-726

© SAP AG 2007

Object Compare Between Development and Production

2.481Different Versions in DEV and PRD

143Objects only in PRD

2.923Objects only in DEV

Number of inconsistenciesCategory

There is a high number of inconsistent objects between DEV and PRD. If there is a high number of inconsistent objects between DEV and PRD, the systems might

behave differently. Outdated objects, which are not valid in PRD might be changed in DEV and transported to PRD again. Therefore, it is a risk for productive operation.

Reasons for inconsistencies can be: Transport sequence violations, canceled transports, changes directly in production, wrong initial setup of the systems, …

© SAP AG E2E200 10-727

© SAP AG 2007

Repository Comparison with Transaction SREPO

Mass comparison of the repositories of two SAP systems You can compare the following sets of objects: • All customer objects and modified SAP objects • All customer objects • All modified SAP objects • All objects in a package • All objects in a transport request

Object list with information from the compared versions: • Green - Identical • Red - Not identical • Yellow - Objects cannot be compared directly

© SAP AG E2E200 10-728

© SAP AG 2007

Customizing Comparison with Transaction SCU0

This tool compares customizing objects in two clients, either on the same or different SAP systems.

To compare objects, start the Customizing Cross-System Viewer in the logon client. Logon to the comparison client.

The Customizing Cross-System Viewer generates comparisons for selected customizing objects, which are saved as a work-list in the database.

You can make any number of comparisons with each work-list, in dialog or background. A comparison shows the differences for each object. You can also make an individual comparison for each object.

© SAP AG E2E200 10-730

© SAP AG 2007

Change Request Management KPIs for IT Reporting

Goal:

Change Request Management is the efficient and punctual implementation of SAP software changes, with minimal risks usingstandardized methods and procedures.

KPIs:Number of change requests per time unit and status Approval/realization time of change requests per priority and categoryNumber of urgent corrections compared with normal correctionsNumber of rejected and approved change requests

© SAP AG E2E200 10-731

© SAP AG 2007

Change Request Management Reporting: Urgent Corrections

To navigate to change transaction (here: urgent correction) double-click relevant entry in column

Transaction ID

The result is a list of all urgent corrections in the last six months.

© SAP AG E2E200 10-732

© SAP AG 2007

Number and Average Runtime of Change Requests

18,675NormalMedium

2,410Urgent

12,450NormalHigh1,815Urgent

8,23NormalVery High

Total

Low

Priority

2,226Urgent

16,1133Normal

00Urgent

19,35Normal

4,91Urgent

Average Runtime (Days)

NumberCategory

This analysis shows the average runtime of change requests per priority and category. The average runtime of normal corrections is 16 days. The average runtime of urgent

corrections is 2 days. The overall number of changes in the selection period is 159. The amount of urgent

corrections is 16%. This is a high value.

© SAP AG E2E200 10-733

© SAP AG 2007

Number and Rejected and Approved Change Requests

76ApprovedMedium

5Rejected

60ApprovedHigh2Rejected

18ApprovedVery High

Total

Low

Priority

22Rejected

133Approved

5Rejected

5Approved

10Rejected

NumberCategory

This analysis shows the number of rejected and approved change requests. 14% of all requests were rejected.

© SAP AG E2E200 10-735

© SAP AG 2007

Maintenance Management KPIs for IT Reporting

Goal:

Maintenance supports the customer in planning and downloading the available SAP software patches and updates for the complete solution landscape.

KPIs:Comparison of the customer releases and support package level with SAP guidelinesSame maintenance level in the transport landscape through the technology stackFrequency of planned maintenance

© SAP AG E2E200 10-736

© SAP AG 2007

Overview of Productive Systems

40B01.11.1998ProductiveR/3R/3 Italy120019896

45B01.10.1998ProductiveR/3R/3 France120019786

45B01.06.1998ProductiveR/3R/3 GB120014123

31H21.01.1998ProductiveR/3R/3 USA120014122

40B01.03.1998ProductiveR/3R/3 Turkey120010708

45B20.08.1997ProductiveR/3R/3 Spain120014830

45B01.01.1998ProductiveR/3R/3 Germany120011917

40B01.09.2003ProductiveSRMEBP Call-Off20141452

31I01.08.2003ProductiveAPOAPO20131230

DemoWEB ASWebAS20101300

31I01.05.2001ProductiveBWBW call off20081864

Rel.First Go-LiveUsageProductInst. DescriptionInst. No.

This table shows an overview of the installed systems in a productive solution. You can check the usage, the first Go-Live and the release. With this inventory list, you can get a good overview of the whole system landscape. All of these systems are already out of maintenance!

© SAP AG E2E200 10-737

© SAP AG 2007

System History for a Transport Landscape

14.07.2006ERP 2004System Copy PRD -> QAS

June 20064.6B -> ERP 2004Upgrade PRDApril 20064.6B -> ERP 2004Upgrade DEVAugust 20003.1I -> 4.6BUpgrade PRD20003.1I -> 4.6BUpgrade DEVJanuary 19993.0F -> 3.1IUpgrade PRD19983.0F -> 3.1IUpgrade DEVJune 19973.0FInstallation PRD19963.0F Installation DEV

DateTarget-ReleaseStep

This table shows the system history of a transport landscape.

© SAP AG E2E200 10-738

© SAP AG 2007

Maintenance Level in a Transport Landscape

0004

0000

0009

0013

0013

0009

0013

0009

0008

0005

0005

0004

0005

0005

0005

0005

0005

Level in QAS

000400042005_1_640ST-PI

0000000001H_ECC500ST-A/PI

00090009500SAP_HR

00130013350SAP_BW

00130013640SAP_BASIS

00090009500SAP_APPL

00130013640SAP_ABA

001000092004_1_640PI_BASIS

000900082004_1_500PI

00050005500EA-RETAIL

00050005500EA-PS

00040004300EA-IPPE

00050005500EA-HR

00050005500EA-GLTRADE

00050005500EA-FINSERV

00050005500EA-DFPS

00050005500EA-APPL

Level in PRDLevel in DEVReleaseComponent

This table shows the different maintenance levels along the transport landscape. There should be no inconsistencies.

© SAP AG E2E200 10-739

© SAP AG 2007

Age of Implemented Support Packages

0600_620 WP-PI

05.08.20042003C_620 ST-PI

27.08.2004001E_R3_470ST-A/PI

21.12.200550470SAP_HR 07.12.200557620SAP_BASIS

27.10.200525470SAP_APPL

07.12.200557620SAP_ABA

01.07.2005102004_1_620PI_BASIS

01.08.200592004_1_470PI 27.10.200510200EA-RETAIL 27.10.200510200EA-PS 11.10.200520200EA-IPPE 21.12.200531200EA-HR 27.10.200510200EA-GLTRADE 27.10.200510200EA-FINSERV 27.10.200510200EA-DFPS 27.10.200510200EA-APPL

27.10.200515100ABA_PLUS

Date of Support PackageLevelReleaseComponent

This table shows when the installed support package was delivered. If the support package level is older than one year, a support package implementation project should be scheduled.

© SAP AG E2E200 10-741

© SAP AG 2007

Test Management KPIs for IT Reporting

Goal:

Test Management supports the customer in planning, preparing, executing and evaluating test cycles. Testing is used to identify the characteristics of a software solution and to point out the difference between actual and required states.

KPIs:Number of available test casesNumber of failed and succeeded test cases in a test cycleRetention time of transport requests in the test systemNumber of incidents after the Go-Live of a change

© SAP AG E2E200 10-742

© SAP AG 2007

Status Analysis – Test Plan Results

Overview:Test status of the whole test

plan

Overview : Test status on the scenario level

Test status on the test case

level

Overview :Test status on the process

level

You can also narrow your selection in a certain test plan. As a result, you see the number of test cases in status Error, No Result or OK on the different

levels of the test plan.

© SAP AG E2E200 10-743

© SAP AG 2007

Testing Time in QAS - Test

23%540No Testing: Less than 5 minutes

14%324Insufficient Testing: Less than ½ hour

16%360Short Testing: More than ½hour but less than 1 day

47%1.091Intensive Testing: More than 1 day

Transport requests in %

Number of transportsTime spent in Quality Assurance System

This analysis shows how long the transport requests have spent in the test system. In this example, 37% of all transport requests spent less than half an hour in the quality assurance system, before they were forwarded into production.

This means that these transport requests were not properly tested.

© SAP AG E2E200 10-744

© SAP AG 2007

Service Desk Messages after a Go-Live

An important key figure for the quality of testing is the number of incidents in the week after the Go-Live. Is the number of incidents significantly higher than in other weeks?

© SAP AG E2E200 10-746

© SAP AG 2007

Solution Quality Reporting KPIs

Goal:

Solution Quality Reporting measures the overall quality, performance and availability of a solution.

KPIs:Number of ABAP dumps and Update errorsAverage response time in dialogAvailability – planned and unplanned downtime

© SAP AG E2E200 10-747

© SAP AG 2007

SAP EarlyWatch Alert – Content

System Configuration

Performance Overview

Workload Distribution

SAP System Operations

Hardware Capacity

Database Performance

Database Administration

Trend Analysis

What is the Early Watch Alert? Important system data is transmitted from the SAP customer system to SAP at regular

intervals, via the remote connection. The data transferred includes only technical data with non sensitive content, which is

transparent and manageable in transaction SDCCN. SAP analyzes this data and provides a clear overview of the results in a report, which can be

downloaded from SAP Solution Manager.

© SAP AG E2E200 10-748

© SAP AG 2007

Key Performance Indicators from EWA

down66.34- GBLast Month DB Growth

steady176.28 GBDB SizeDatabase Space Management

up350 msAvg. DB Request Time in Update Task

up271 msAvg. DB Request Time in Dialog TaskDatabase Performance

steady100 %Avg. Availability per Week

up556 msAvg. Response Time at Peak Dialog Hour

steady35114Max. Dialog Steps per Hour

up580 msAvg. Response Time in Dialog Task

up462Active UsersSystem Performance

TrendValueIndicatorsArea

This table shows important key performance indicators in various system areas.

© SAP AG E2E200 10-750

© SAP AG 2007

System Errors per Week (EWA)

7733110014.05.2006

5034610007.05.2006

8643110030.04.2006

934719523.04.2006

1601949716.04.2006

7424710002.04.2006

713129926.03.2006

Update ErrorsProgram Errors (ABAP)Availability (%)Date

This table shows the system errors per week. The number of ABAP dumps is an important KPI for the quality of the solution. It should be

monitored regularly. Depending on the system size, the value should be lower than 100 per day. If the value is very high, then activities must be started to reduce the number of ABAP dumps. The number of ABAP dumps can be retrieved from the Early Watch Alert report or in

transaction ST22.

© SAP AG E2E200 10-751

© SAP AG 2007

History of ABAP dumps and Update Errors

0

500

1000

1500

2000

2500

3000

3500

4000

4500

15.0

6.20

05

15.0

7.20

05

15.0

8.20

05

15.0

9.20

05

15.1

0.20

05

15.1

1.20

05

15.1

2.20

05

15.0

1.20

06

15.0

2.20

06

15.0

3.20

06

15.0

4.20

06

15.0

5.20

06

15.0

6.20

06

15.0

7.20

06

15.0

8.20

06

15.0

9.20

06

[weeks]

[num

ber]

Program Errors (ABAP) Update Errors

This diagram shows the number of ABAP dumps and Update errors in the last months. Some days had an extremely high number of system errors.

© SAP AG E2E200 10-752

© SAP AG 2007

Transport9LOAD_PROGRAM_LOSTAppl573MESSAGE_TYPE_X

Appl689DYNPRO_SEND_IN_BACKGROUNDIT1284DBIF_RSQL_SQL_ERRORAppl2177SYNTAX_ERRORUser3490TIME_OUTCategoryNo.Top 5 ABAP Dumps in the last six months

Quality Risk

Technical Analysis of the ABAP Statistics shows many dumps related to category application. These dumps could be avoided by improving the testing in quality assurance.

Category of ABAP Dumps

The different categories of ABAP dumps are: • Appl – runtime errors that should be found (caught) in QA during testing, thus indicating

insufficient testing • IT – technical system problems (e.g. with DB, OS); in most cases such errors cannot be

detected in QA • User behavior – dumps caused by a wrong end-user handling of an application • Transport – reason for the runtime errors is importing during time of high system activity

The different categories of dumps indicate weaknesses in the application management. If most

dumps are of category “Application”, then the development and test process could be improved. If most dumps are of category “IT”, then the technical system administration could be improved.

© SAP AG E2E200 10-754

© SAP AG 2007

History of Response Times

This graphic shows the average response times of a customer system over a period of 4 months. There is a significant increase in the avg. dialog response time from 900 ms in the beginning, to close to 1400 ms in the end.

A more detailed analysis showed that this is due to increased transaction volume after several roll-out waves.

© SAP AG E2E200 10-755

© SAP AG 2007

Workload Analysis

The data for the average response time can be taken from the workload overview (transaction ST03). The average response time in dialog should be less than 1 second.

© SAP AG E2E200 10-757

© SAP AG 2007

System Availability Reporting – How to Get There

Navigation to System Availability Reporting

© SAP AG E2E200 10-758

© SAP AG 2007

System Availability Reporting – System Selection

Selection of systems to be reported of

To selection details

Manual maintenance of system availability (status of system availability often has to be clarified personally with customers)

© SAP AG E2E200 10-759

© SAP AG 2007

System Availability – Manual Maintenance

Standard options (can be modified)

Standard reasons (can be modified)

© SAP AG E2E200 10-761

© SAP AG 2007

Two Methods for Availability Reporting

ST03 Based Availability Reporting:Is the habitual method working in each EWA Is based on the evaluation of the ST03* performance collector log

Advantages: EWA standard procedure; no customizing required Easy to set up in the SLR

Disadvantages:Only supports monitoring of the availability object "SAP system".The measured value for "SAP system" availability is influenced by a multitude of external factors.Measurement resolution and accuracy only satisfies low-end requirements. Planned downtimes are not supported.

Availability Types • "System availability"

Measurement Resolution and Accuracy • The availability information is derived from the ST03 collector run. The measurement

resolution is one sample per hour, since the ST03 collector only runs once per hour. • In total there are 24 availability probes per day. This results in an accuracy of approx. ±4%

for each day. Availability Formats • "24h-Availability" • "Critical Uptime Availability" (called "Availability for critical periods")

Technical Prerequisites • Periodical execution of ST03 collector batch job

SAP_COLLECTOR_FOR_PERFMONITOR

© SAP AG E2E200 10-762

© SAP AG 2007

Two Methods for Availability Reporting

CCMS Ping-based Availability Reporting:Is the enhanced reporting method for high accuracy demands

Advantages: Supports monitoring of different availability objects like "SAP system", "SAP instances", "SAP logon-groups" Provides high resolution measurement Provides exact timestamps for each single downtime incidence Supports maintenance of planned downtimes Provides a dynamic calendar for planned downtimes and critical uptimes for up to one year

Disadvantages: Effort for setup and customizing of CCMS Ping agents, CCMS and CPH requiredCurrently only available inside Service Level Reporting

Availability Types • "System availability - ABAP stack" • "System availability - JAVA stack" • "Instance availability" • "Instance logon availability" • "Logon-group availability"

Measurement Resolution and Accuracy • The availability information is derived from a CCMS ping agent. The highest measurement

resolution is one sample per minute for system- and instance availabilities and one sample every five minutes for instance logon- and logon-group logon availabilities.

• In total there are 1440 or 288 availability probes per day. This results in an accuracy of approx. ±0,07% or ± 0,35% for each day.

Availability Formats • "24h-Availability" • "24h-Availability, planned downtimes-adjusted" • "Critical Uptime Availability" • "Critical Uptime Availability, planned downtimes-adjusted"

© SAP AG E2E200 10-764

Technical Prerequisites • CCMS ping agent running on any host • CCMS Central Performance History configured to collect MTE-classes of context

"Availability"

© SAP AG E2E200 10-765

© SAP AG 2007

Planned Outages by Category

In this example, the customer has reported the times of planned outages per category. Most planned outages are caused by the hardware, followed by the database and the Storage Area Network (SAN). This customer is in a roll-out process and upgrades the hardware frequently.

© SAP AG E2E200 10-766

© SAP AG 2007

Unplanned Outages by Category

With regard to the unplanned incidents, the SAP system causes most outages, followed by the Storage Area Network (SAN) and database.

© SAP AG E2E200 10-767

© SAP AG 2007

IT Reporting for Change Control – Summary I

Change Diagnostics:Number of changes in the parameter configuration per time unitInconsistencies in the parameter configuration within the transport landscape and within the productive environmentCompleteness of landscape description in SAP Solution Manager

Change Deployment:Number of transports in the system per time unitNumber of errors during the transports per time unitModification level of the systemsConsistency of the transport landscape

Change Request Management:Number of change requests per time unit and statusApproval/realization time of change requests per priority and categoryNumber of urgent corrections compared with normal correctionsNumber of rejected and approved change requests

© SAP AG E2E200 10-768

© SAP AG 2007

IT Reporting for Change Control – Summary II

Maintenance Management:Comparison of the customer releases and support package level with SAP guidelinesSame maintenance level in the transport landscape through the technology stackFrequency of planned maintenance

Test Management:Number of available test casesNumber of failed and succeeded test cases in a test cycleRetention time of transport requests in the test systemNumber of incidents after the Go-Live of a change

Solution Quality Reporting: Number of ABAP dumps and Update errorsAverage response time in dialogAvailability – planned and unplanned downtime

© SAP AG E2E200 10-769

© SAP AG 2007

Unit Summary

Now you are able to:

Describe KPIs which are relevant for IT Reporting for Change Control

Know data sources to build up IT Reporting for Change Control

© SAP AG E2E200 10-770

Exercises

Unit: IT Reporting for Change Control

In this exercise, you can check your knowledge on IT Reporting for Change Control


10-1 Which areas are relevant for IT Reporting for Change Control?


True False

Root Cause Analysis

Test Management

Interface Management


10-2 Where can you determine the number of transport requests that were imported in the

last six months? Please choose the correct answer.

Import Buffer

Import History

© SAP AG E2E200 10-771

Job Overview

10-3 Which KPIs are defined for Change Deployment


True False

Number of transports in the system per time unit

Number of test cases

Average response time in dialog

Consistency of the transport landscape

© SAP AG E2E200 10-772

Solutions


10-1 Which areas are relevant for IT Reporting for Change Control?


True False

O X Root Cause Analysis

X O Test Management

O X Interface Management

X O Maintenance Management

10-2 Where can you determine the number of transport requests that were imported in the last

six months?


O Import Buffer

X Import History

O Job Overview

© SAP AG E2E200 10-773

10-3 Which KPIs are defined for Change Deployment


True False

X O Number of transports in the system per time unit

O X Number of test cases

O X Average response time in dialog

X O Consistency of the transport landscape

e2e200 en 40 change control management 2007

Documents