E2E200 Change Control Management
E2E200
Change Control Management
THE BEST-RUN BUSINESSES RUN SAP © SAP AG 2006
© SAP AG 2007
SAP Solution Manager 4.0 2007/Q2 Materialnummer: 50084558
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.
© SAP AG 2006
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.
Course Prerequisites Required Knowledge: Fundamentals of SAP Software Change Management Basics of SAP Solution Manager
Recommended Knowledge: End to End Solution Support (E2E050)
© SAP AG 2006, Title of Presentation / Speaker Name / 1
Course Goals This course will enable you to: 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.
© SAP AG 2006, Title of Presentation / Speaker Name / 1
Target Audience 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
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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.
Course Content Preface 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
Appendixes
© SAP AG 2006, Title of Presentation / Speaker Name / 1
Unit 6
Transport Strategies
Unit 7
Change Request Management
Unit 8
Maintenance Management
Unit 9
Test Management
Unit 10 IT Reporting for Change Control
End-to-End Curriculum
E2E100
5 days
C_E2E100
5 days
C_E2E200
5 days
C_E2E300
E2E Root Cause Analysis
E2E200
E2E Change Control Management
E2E050 E2E Solution Support
E2E300
E2E Integration & Automation
E2E400
2 days
Technical Upgrade Management
© SAP AG 2006, Title of Presentation / Speaker Name / 1
Application Management Expert – Root Cause Analysis Application Management Expert – Change Control Management Business Process Expert
C_E2E400 Technical Quality Manager for Upgrade Projects
Introduction to E2E Change Control Management
Introduction to E2E Change Control Management Solution Landscape Documentation E2E Change Diagnostics Netweaver Development Environments Enhanced Change and Transport System Transport Strategies Change Request Management Maintenance Management Test Management IT Reporting for Change Control © SAP AG 2007
© SAP AG
E2E200
1-9
Introduction to E2E Change Control Management Content Objectives 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 2007
© SAP AG
E2E200
1-10
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 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 2007
© SAP AG
E2E200
1-11
Introduction to E2E Change Control Management: Unit Overview Diagram Introduction to E2E Change Control Management Lesson 1: Objectives of E2E Change Control Management Lesson 2: Standards for SAP E2E Solution Operations Lesson 3: Standards for SAP E2E Change Control Management
© SAP AG 2007
© SAP AG
E2E200
1-12
Objectives of E2E Change Control Management Objectives Transparency of current software configuration and recent changes Fast realization of business demands Defined approval procedure for change requests High quality and stability of the production environment
© SAP AG 2007
© SAP AG
E2E200
1-13
SAP Standards for E2E Change Control Management Transparency of current software configuration and recent changes
Defined Approval Procedures Change Request Management
Change Diagnostics Change Request Management
Fast realization of business demands
High quality and stability of the productive environment
Change Deployment
Maintenance Management Test Management Change Request Management
© SAP AG 2007
© SAP AG
E2E200
1-14
Different Focus of Business Unit and IT Business Unit
IT
Fast reaction on business demands
Solid operation
Less formalism and bureaucracy
Solid change management
Less time to test
Only planned transports
Focus on own business
Only tested and approved changes into production
© SAP AG 2007
Often there is a conflict between business requirements for fast changes and operation requirements for stable environments.
© SAP AG
E2E200
1-15
Introduction to E2E Change Control Management: Unit Overview Diagram Introduction to E2E Change Control Management Lesson 1: Objectives of E2E Change Control Management Lesson 2: Standards for SAP E2E Solution Operations Lesson 3: Standards for SAP E2E Change Control Management
© SAP AG 2007
© SAP AG
E2E200
1-16
Standardized E2E Solution Operations
Customer’s Business Unit Global Business Process Champion Regional Business Process Champion
End User Incident and problem management
PMO (Program Office) Requests for change
Customer’s IT Application Management Upgrade & life cycle management, application diagnostics
Custom Development
Business Process Operations Integration & automation
System diagnostics/administration SAP NetWeaver Team
IT Infrastructure SAP Standards in Operations reduce Total Cost of Operations and enable Mission Critical Support © SAP AG 2007
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-17
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-18
SAP Standards for E2E Solution Operations Incident Management Business Process Champion Exception Handling Data Inconsistencies
Program Management Office Change Request Management Upgrade Enterprise Service-Oriented Architectures
Application Management Root Cause Analysis Change Control Management Minimum Documentation Remote Supportability
© SAP AG 2007
© SAP AG
E2E200
1-19
SAP Standards for E2E Solution Operations Business Process Operations Business Process and Interface Monitoring Data Volume Management Job Scheduling Management Transactional Consistency
Custom Development SAP Technical Operations System Administration System Monitoring
© SAP AG 2007
© SAP AG
E2E200
1-20
Curriculum for SAP Solution Operations Customer’s Business Unit PMO (Program Office) Management Competence (Master)
Technical Quality Management
Customer’s IT
Application Management
Business Process Operations
SAP NetWeaver Team
Technical Core Competence (Associate) SAP Technology & E2E Solution Support E2E Root Cause Analysis
E2E Change Control Management
E2E Business Process Integration & Automation
SAP Technology
SAP System Administration
Technical Expert Competence (Professional)
Technical Upgrade Management
EP Diag
Change Request
Business Process Performance
XI Diag
Software Log.
Job Scheduling
BI Diag
Test Mgmt
WebAs (DBs) Diag
Data Volume Mgmt
SolMan Impl.
Integration Mgmt
Security
EP Admin
XI Admin
BI Admin
Core WebAS (DBs)
© SAP AG 2007
© SAP AG
E2E200
1-21
Introduction to E2E Change Control Management: Unit Overview Diagram Introduction to E2E Change Control Management Lesson 1: Objectives of E2E Change Control Management Lesson 2: Standards for SAP E2E Solution Operations Lesson 3: Standards for SAP E2E Change Control Management
© SAP AG 2007
© SAP AG
E2E200
1-22
Control the Changes during the whole Application Livecycle Solution Design
Solution Maintenance
Solution Correction
Global / Regional Business Process Champion Solution Architecture
SAP Maintenance Management
End User / Key User Incident Management
Program Management Office Change Request Management
Application Management Test Management Workbench / Customizing Changes Custom Development
Change Deployment
Application Change Diagnostic
Correction & Transport System SAP NetWeaver Team
System Change Diagnostic
DB / OS / HW Changes & Maintenance IT Infrastructure
© SAP AG 2007
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. Endusers, 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-23
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-24
Introduction to E2E Change Control Management: Unit Overview Diagram Introduction to E2E Change Control Management Lesson 1: Objectives of E2E Change Control Management Lesson 2: Standards for SAP E2E Solution Operations Lesson 3: Standards for SAP E2E Change Control Management Change Diagnostics Change Deployment Change Request Management Maintenance Management Test Management
© SAP AG 2007
© SAP AG
E2E200
1-25
Change Diagnostics – Typical Questions
How many transports were imported last week? Did we change any technical configuration parameters?
When did we import support packages?
Is there ONE place where all changes in the solution are listed
Did we change anything last Tuesday?
© SAP AG 2007
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-26
Change Diagnostics: Overview E2E Change Analysis Tools Configuration and File Reporting Type of changes
Technical Configuration
Enhanced Change and Transport System
Patches, SP, Release
Business Configuration
“Content” EP, XI, BI, SLD
Coding
Changes to Production Productive Environment Documented in SAP Solution Manager (SMSY)
© SAP AG 2007
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-27
Capture and Manage the system landscape centrally in SAP Solution Manager FVS System Landscape Directory
PLM
Solution Landscape CUS
CUS SCM
4.6C
server, databases, systems, system components
Solution Manager System Landscape (SMSY)
© SAP AG 2007
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-28
Change Analysis, Configuration & File Reporting Architecture Overview E2E Change Analysis
Number of Changes
InfoCube
Data Collection once a day
Data Collection once a day
SMD Agents
Solution Tool Plugins Solution Manager Diagnostics
JAVA based installations
Config Store
ABAP based installations
Parameter Values
Configuration and File Reporting © SAP AG 2007
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-29
Change Diagnostics: Characteristics Change Diagnostics provides transparency on the current software configuration and recent changes in the solution landscape.
Change Diagnostics: Efficient Root Cause Analysis: Provides a central entry point
for analyzing changes in a solution Provides accurate information on configuration parameters
and their history. For example, database parameters, ABAP parameters and JAVA parameters. Enables the organization to standardize the solution
configuration Documentation of the solution landscape in the SAP Solution
Manager Transport statistics and KPI’s on the quality of the solution
© SAP AG 2007
© SAP AG
E2E200
1-30
Introduction to Change Control Management: Unit Overview Diagram Introduction to E2E Change Control Management Lesson 1: Objectives of E2E Change Control Management Lesson 2: Standards for SAP E2E Solution Operations Lesson 3: Standards for SAP E2E Change Control Management Change Diagnostics Change Deployment Change Request Management Maintenance Management Test Management
© SAP AG 2007
© SAP AG
E2E200
1-31
Change Deployment – Typical Questions
Did we record application changes automatically ?
How can we change ABAP & Java components synchronously ?
Is our development system up to date ?
How can we avoid transport sequence errors?
How to manage heterogeneous development environments?
© SAP AG 2007
© SAP AG
E2E200
1-32
Enhanced Change and Transport System (CTS+)
ABAP change
ABAP change
Java change
Java change
ABAP CTS
…
…
Transport of ABAP Transport Controller
Virtual QAS
Virtual PRD
Java DEV
Java QAS
Java PRD
Non-ABAP
Non-ABAP
Non-ABAP
SAP NetWeaver Application Server CTS+
ABAP transport objects Enterprise Portal objects (EPA, PAR) Objects of NWDI (SCAs,…) Objects from XI Interface for Non-SAP applications
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 © SAP AG 2007
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-33
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 Deployment Management of heterogeneous development environments One common tool for software logistics of ABAP and non-ABAP
systems Non-ABAP applications inherit all properties of the ABAP Change
and Transport System in terms of documentation, tracking and troubleshooting features Consistent distribution of changes within a solution SAP‘s best practises in transport management
© SAP AG 2007
© SAP AG
E2E200
1-34
Introduction to E2E Change Control Management: Unit Overview Diagram Introduction to E2E Change Control Management Lesson 1: Objectives of E2E Change Control Management Lesson 2: Standards for SAP E2E Solution Operations Lesson 3: Standards for SAP E2E Change Control Management Change Diagnostics Change Deployment Change Request Management Maintenance Management Test Management
© SAP AG 2007
© SAP AG
E2E200
1-35
Different Levels of Control
Change Request Management SAP Solution Manager Improved Documentation
Better Control
Enhanced Change and Transport System (CTS+)
SAP System ABAP Stack Improved Documentation
ABAP
Better Control
Java
.net
…..
© SAP AG 2007
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-36
Change Request Management – Sample Process
Change Request Management
Service Desk
SAP Solution Manager Service Desk Employee
Service Message
Change Request Developer
Feedback
Requester
Change Manager
PRD
Controlled transports
Tester
Change Document
Task List
QAS
Controlled transports
Maintenance Cycle
IT Operator
DEV
© SAP AG 2007
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-37
Three Tiers of Change Request Management SAP Solution Manager Change Admin Management of all
change requests Change request
categorization Change
documentation
Project Management Project planning
& budgeting
Change Logistics Customizing &
Development (Realization)
Project
documentation Customizing &
Development (Specifications)
Test execution Seamless
integration into TMS
Approval
workflow
Test management
Transport
scheduling Status reporting Transport Complete change
tracking
history
© SAP AG 2007
© SAP AG
E2E200
1-38
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 changes Full documentation of each change: Each change in the
system has a link to a Change Request and a Service Desk Changes can be scheduled according to priority, category
and possible impact All changes have to follow an established workflow. Only
changes which are approved and tested come into production Change Request Management incorporates SAP’s best
practises in transport management Management of Non-ABAP systems is possible
© SAP AG 2007
© SAP AG
E2E200
1-39
Introduction to E2E Change Control Management: Unit Overview Diagram Introduction to E2E Change Control Management Lesson 1: Objectives of E2E Change Control Management Lesson 2: Standards for SAP E2E Solution Operations Lesson 3: Standards for SAP E2E Change Control Management Change Diagnostics Change Deployment Change Request Management Maintenance Management Test Management
© SAP AG 2007
© SAP AG
E2E200
1-40
Enhancement and Maintenance to adopt Innovation 2005
2006
2007
2008
2009
2010
Enhancement Packages
Next Release
mySAP ERP 2005 SAP NetWeaver
Customers Adopt Innovation at their Pace Process and User Interface Simplification
Industry-Specific Enhancements
New Enterprise Services
Cross-Industry Functional Enhancements
© SAP AG 2007
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-12 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-41
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-42
Support Package Stacks (SP Stacks) SAP releases sets of
Support Packages per product and per quarter – the SAP Support Package Stacks (SP Stacks)
R/3 Appl.
Support Packages & patches of SP Stacks must be used in the given combination. Other combinations only apply in 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
ABA Basis Kernel
APO Appl. ABA Basis Kernel
BW Appl. ABA Basis Kernel
Q1
Q2
Q3
Q4
t
© SAP AG 2007
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-43
Maintenance Schedule 2007
2008
2009
Implementation Projects Market Campaign Complaint Management Rollout Brazil
SAP Maintenance SP Stack Hot News Top Notes Incident
One or two times per year ….
….
Periodic review and corrections Urgent Corrections Notes/Patches
….
© SAP AG 2007
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-44
Optimized Process for support package stacks Maintenance Optimizer
SAP HotNews Inbox
SAP Solution Manager
SAP Solution Manager
Display relevant corrective SAP software packages
Retrieve relevant HotNews from SMP
Approve download
Decide on relevance
Download
Download
Approve Import
Approve Import
Test
Test
Release to production
Release to production
© SAP AG 2007
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-45
Maintenance Management: Characteristics The goal of Maintenance Management is to keep applications up to date 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 solution Support Packages include the most recent legal changes Troubleshooting is faster on a current support package level
as many possible root causes are already eliminated Implementing a SAP note often requires the implementation of
many dependent notes if the support package level is old Implementation projects or connected systems often require a
current support package level
© SAP AG 2007
© SAP AG
E2E200
1-46
Introduction to E2E Change Control Management: Unit Overview Diagram Introduction to E2E Change Control Management Lesson 1: Objectives of E2E Change Control Management Lesson 2: Standards for SAP E2E Solution Operations Lesson 3: Standards for SAP E2E Change Control Management Change Diagnostics Change Deployment Change Request Management Maintenance Management Test Management
© SAP AG 2007
© SAP AG
E2E200
1-47
Testing along the Software Lifecycle Implementation Project
Business Blueprint Doc Test Concept
Realization Development, Test
Final Preparation and Go Live
Testing & Bug Fixing is ~30% of total project effort
Review
Unit Test (Debugging)
Bug Fixing
Review
Integration Test
Test Case Development
Bug Fixing
Test planning
Business Blueprint
User Acceptance Test
Project Preparation
OK
Functional sign off
System sign off Regression Test / Volume Test
OK
© SAP AG 2007
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-48
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 significantly Continuous tracking and status analysis of the test progress Clear and detailed test descriptions Reproducible test results Identification of the most important test cases
© SAP AG 2007
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-49
Course Content Change Diagnostics
Change Request Management
Unit 2
Solution Landscape Documentation
Unit 7
Unit 3
E2E Change Diagnostics
Unit 10 IT Reporting for Change Control
Change Request Management
Maintenance Management Unit 8
Maintenance Management
Change Deployment
Test Management
Unit 4
NetWeaver Development Environments
Unit 9
Unit 5
Enhanced Change and Transport System
Unit 6
Transport Strategies
Test Management
© SAP AG 2007
© SAP AG
E2E200
1-50
End to End Diagnostics: Unit Summary You should be able to explain: Objectives 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 2007
© SAP AG
E2E200
1-51
Solution Landscape Documentation
Introduction to E2E Change Control Management Solution Landscape Documentation E2E Change Diagnostics Netweaver Development Environments Enhanced Change and Transport System Transport Strategies Change Request Management Maintenance Management Test Management IT Reporting for Change Control © SAP AG 2007
© SAP AG
E2E200
2-52
Solution Landscape Documentation Contents: SAP Solution Manager System Landscape System Landscape Directory Solutions Projects Business Processes
© SAP AG 2007
© SAP AG
E2E200
2-53
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 2007
© SAP AG
E2E200
2-54
End-to-End Business Processes are a Challenge for Solution Operation Spread Sheet
EP 7.0 EP 6.0
Siebel CRM BW
XI Manugistics
Legacy System
Outlook External Web
People soft HR
Documentum R/3
© SAP AG 2007
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-55
SAP Solution Manager Architecture SAP Solution Manager Roadmap, Blueprint and Implementation Change Diagnostics
Maintenance Optimizer
Testing
P
je ro
ct
s
tio lu o S
Application Management
n Service Desk
Change Request Management
BPR
Implementation Content
Business Processes
Documentation Systems
SAP ERP
NW BI
NW XI
Other
© SAP AG 2007
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-56
Solution Landscape Documentation Unit Overview Diagram Solution Landscape Documentation Lesson 1: Solution Manager System Landscape (SMSY) Lesson 2: System Landscape Directory Lesson 3: Solutions Lesson 4: Projects Lesson 5: Business Processes
© SAP AG 2007
© SAP AG
E2E200
2-57
Solution Manager Data Model (Transaction SMSY) Product
System / Product Version
Main Instance
Logical System
Customer system landscapes Logical component A
Product
System
ABAP
QA system
DEV system
Client 002
… system
PRD system
Client 200 Client …
Logical component B
J2EE
DEV system
QA system
PRD system
… system
TREX Project 2 Project 1
Logical component A DEV
QA
PRD
Logical component B DEV
QA
PRD
Solution 2 Solution 1
Logical component A DEV
QA
PRD
Logical component B DEV
QA
PRD
© SAP AG 2007
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-58
How to Create Systems in SMSY SAP Solution Manager
1.
SAP ABAP System
Choose Product Pull via RFC
2.
Create New System
3.
Setup RFC Destinations
4.
Read System Data
SAP Java System No automatic data transfer
SMSY
© SAP AG 2007
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-59
System-Demo SMSY
System-Demo
© SAP AG 2007
© SAP AG
E2E200
2-60
Create New System
© SAP AG 2007
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-61
Setup RFC Destinations
RFC Read Access: RFC to read data from satellite systems RFC for Change Manager: RFC for Change Request Management Trusted System RFC: Log on to managed system as trusted user RFC for Solution Manager: Log on to managed system
© SAP AG 2007
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-62
Read System Data
Automatically collect data on Clients and Support Package Levels © SAP AG 2007
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-63
Schedule Periodic Data Transfer
Schedule an automatic data transfer once per day All systems in SMSY are updated. New systems can be added from TMS or SLD
© SAP AG 2007
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-64
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 sheets Impact Analysis in the case of hardware and software changes or in case of unplanned downtimes Check system inventory in case of as-is analysis in projects, system landscape planning or in order to guarantee a homogeneous system landscape Solution Manager Key Generation in case of installation or upgrade to SAP NetWeaver04s based solutions and higher
© SAP AG 2007
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-65
Transaction SMSY: Software and Hardware Inventory
SID, Product, Main Instance
Installation Number Data Source Message Server, System Nr., DB
Software Components and version information
© SAP AG 2007
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-66
Where Used List of Systems
© SAP AG 2007
© SAP AG
E2E200
2-67
System Landscape Analysis System landscape analysis by landscape components (Transaction: SMSY
Utilities
Analyses)
© SAP AG 2007
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-68
Generate Installation Key
1. 2.
Details in Note 811923 © SAP AG 2007
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-69
Solution Manager Unit Overview SAP Solution Manager Introduction Lesson 1: Solution Manager System Landscape (SMSY) Lesson 2: System Landscape Directory Lesson 3: Solutions Lesson 4: Projects Lesson 5: Business Processes
© SAP AG 2007
© SAP AG
E2E200
2-70
SAP System Landscape Directory
System Landscape Directory System Catalog: Landscape Description
Physical View: Technical System
Master Component Repository
Logical View: Business System
Registered automatically
Maintained at customer site SAP Systems
Data Supplier
Third Party Systems
Component Types Software Catalog: Component Information Landscape Patterns Possible Combinations
Maintained at customer site
Product Update Software Component CIM
Maintained at SAP
Third Party Product & Software Component
© SAP AG 2007
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://
:/sld (where is the SLD server and is the J2EE HTTP port). You will be prompted for a user name and password. © SAP AG
E2E200
2-71
Information Stored in SLD
Component Information Landscape Description Technical Landscape Landscapes Business Landscape
© SAP AG 2007
SLD is part of the J2EE Engine and can be reached using: http://:/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-72
Landscape Description
Installed systems with comprised products and components Includes installed versions and patch levels System topology information (addresses and links) Data by/for SAP NetWeaver Exchange Infrastructure (XI): Application business system names Transport targets for directory content transports Software component versions © SAP AG 2007
© SAP AG
E2E200
2-73
Component Information Software catalog provides information about all available SAP software Includes available version numbers and patch levels Dependencies between components and other relations: Supported platforms and releases for OS, DB, .... Allowed combinations (integration matrix – inter-product dependencies)
Data provided by SAP ( regular update from SAP Service Marketplace) Basis for the description of the system landscape
© SAP AG 2007
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-74
How Does SLD Get Landscape Description Data? Data suppliers collect and send system data to SLD: Must be set up once per landscape element After this, they send reliable and up-to-date data automatically: At the system startup Periodical reporting (batch job)
ABAP System
ABAP Data Supplier
RFC
Java System
Java Data Supplier
HTTP
Other System
Other Data Supplier
C
sldreg (lib/exe)
Gateway
SLD
Java System
HTTP
© SAP AG 2007
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-75
Data Supplier – ABAP-Based Systems
Transaction RZ70
© SAP AG 2007
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-76
Data Supplier – JAVA-Based Systems
© SAP AG 2007
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-77
SAP Solution Manager and System Landscape Directory SAP Solution Manager 1.
SAP ABAP System
Connect SLD to Solution Manager
3.
Create TCP/IP connection
4.
Schedule Periodic Data Transfer from SLD
Configure the SLD Data Supplier
Pull via RFC
Push via RFC
SAP SLD Server 2.
Specify service for communication
SAP Java System Configure the SLD Data Supplier Push via http
Pull via RFC
SMSY
SLD
© SAP AG 2007
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. SAP Solution Manager Connect System Landscape Directory to Solution Manager (transaction SLDAPICUST). Create a TCP/IP connection to the SLD (SM59)
© SAP AG
E2E200
2-78
For automatic data capturing, start the TX SMSY_SETUP and configure the sources System Landscape Directory with the time interval
© SAP AG
E2E200
2-79
SLD Server: Activate the SLD Server Call up the SLD initial page http://:/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-80
Establish Connection from SAP Solution Manager to SLD
© SAP AG 2007
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-81
Landscape Modelling - Today 1
Managing System Solution Manager Solution Manager - IT Governance – (ABAP)
Solution Manager - Diagnostic – (J2EE)
2
3
CIM via HTTP (push)
4
5
RFC calls (poll)
6
RFC calls (push)
Managed Systems
SMD LandScape model with embedded pseudo SLD (J2EE)
6
CIM via RFC (push)
4
ABAP based component SLD Data Supplier (ABAP)
SMSY LandScape model (ABAP)
1 J2EE based component
Local SLD (J2EE)
2
SLD Data Supplier (J2EE) Unmanaged component (C/C++, Java standalone, …)
5 Remote SLD (J2EE)
SLD Data Supplier (SLDREG)
3
© SAP AG 2007
(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-82
Landscape Modelling - Outlook CIM via RFC / HTTP (push)
1 2
Managing system Solution Manager
SLD data via HTTP (push) Regular data synchronization from SLD to SMSY and back Direct ABAP API calls (poll) Direct JAVA API calls (poll)
3
Solution Manager IT Governance –
4 5
Solution Manager - Diagnostic –
Managed systems 4
5
ABAP based component SLD Data Supplier (ABAP)
2 SMSY
Local SLD
3
J2EE based component
Remote SLD
SLD Data Supplier (J2EE)
1 Unified SolMan landscape model
Agent for Non-SAP App (optional)
Unmanaged component (C/C++, Java standalone, …) SLD Data Supplier (SLDREG)
© SAP AG 2007
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-83
Components using SLD
NetWeaver Administrator
Solution Manager
PI/XI
Web Dynpro
SLD
Adaptive Computing Controller
NWDI
© SAP AG 2007
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-84
Reasons to Have Several SLDs
HQ
SAP NetWeaver XI
Geographical distributed locations with local admin groups
DEV
CONS
QA
24
Web Dynpro
7X
SAP NetWeaver Admin.
Improve availability for applications relying on SLD data
Firewall
PROD
…
Isolated production environment
© SAP AG 2007
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-85
Your SLD Topology – A Question of Your Requirements Hosting Provider
Extranet
Organization
Intranet
Intranet
SAP System
SAP System
I nt r anet
SAP System
SAP System
SLD
SLD
SAP System SAP System
SAP System
SAP System
SAP System
Synchronization
SAP System
SLD
SAP System
Automatic forwarding of landscape data
SLD
SAP System
SAP System
Extranet (World Wide Company Network) Region 1
Region 2
SLD
SAP System
Distributed – Several SLDs
Extranet (World Wide Company Network)
SAP System
SLD
Automatic forwarding of landscape data
SAP System
Central – Single SLD
Region 1
Customer 2
Customer 1
SAP System
SAP System
SAP System
SAP System
SAP System
SLD
SAP System
Region 2 Export and import of SLD data
SAP System SLD
SAP System
SAP System
Synchronization of several SLDs – Export/Import
Synchronization of several SLDs – Automatic Forwarding © SAP AG 2007
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-86
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-87
Distribution of Component Information
Customer/ 3rd Party Component Information SAP Master Component Information
SLD Import Import
SLD
SLD
Export All Comp. Information
Import
SLD
© SAP AG 2007
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-88
Export SLD Content
SLD Content can be exported/imported: CR: Component Information LD: Landscape Description NR: Namespace Reservation
© SAP AG 2007
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-89
Example of a Distributed Environment
PI
SLD
PI
PI
SLD
SLD
PI
PI
SLD
SLD
PI
PI
SLD
SLD
PI
PI
Europe
PI
Prod
Asia
Corporate Development
PI
PI
PreProd
QAS
Americas
Development
Transport SLD Content by Export / Import © SAP AG 2007
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-90
Exercise
Exercise
© SAP AG 2007
© SAP AG
E2E200
2-91
Training Systems TT5, hostname: ________ SAP BP for EP MSS http://:55000/irj SLD Content Management & http://:55000/sld
SAP ECC Instance: 50
JCO Client 800
Portal Platform Web AS ABAP
Web AS Java
Front End PC RDBMS Adobe Document Web Browser Services 1.0
Network TT4, hostname: ________
Adobe Document SAP GUI Services 1.0
SAPBPSolution for MSS Manager BP for ESS Diagnostics Content Management & SAP XSS 6.0 http://:50000/smd
SAP Solution Manager Instance: 00
JCO Client 200 Web AS ABAP
Web AS Java
RDBMS
© SAP AG 2007
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 500. The Solution Manager Diagnostics is located on TT4.
© SAP AG
E2E200
2-92
Solution Manager Unit Overview Diagram SAP Solution Manager Introduction Lesson 1: Solution Manager System Landscape (SMSY) Lesson 2: System Landscape Directory Lesson 3: Solutions Lesson 4: Projects Lesson 5: Business Processes
© SAP AG 2007
© SAP AG
E2E200
2-93
SAP Solution Manager Architecture SAP Solution Manager Roadmap, Blueprint and Implementation Change Diagnostics
Maintenance Optimizer
Testing
P
je ro
ct
s
tio lu o S
Application Management
n Service Desk
Change Request Management
BPR
Implementation Content
Business Processes
Documentation Systems
SAP ERP
NW BI
NW XI
Solution Directory
Other
© SAP AG 2007
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-94
Solution Definition
Solution SoftwareComponents
Systems
Scenarios Solution Monitoring Service Desk Change Request Management Collaboration
© SAP AG 2007
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-95
Example: Design of Solutions by Regions
US Solution
US ERP
Asia ERP
US CRM
Asia CRM
Asia Solution
Global BW
Europe ERP
Europe Solution
Europe CRM
© SAP AG 2007
In this example the solutions are separated by regions. The global BW system is part of all solutions
© SAP AG
E2E200
2-96
Example: Design of Solutions by Functional Areas
Gobal ERP
Financial Solution
Global CRM Global BW
Gobal ERP
Logistics Solution
Global CRM Global BW
Gobal ERP
HR Solution
Global CRM Global BW
© SAP AG 2007
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-97
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 limited There is no strict limit, but the number of systems should be limited due to performance and usability aspects The 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 group Are 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!
© SAP AG 2007
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-98
Solution Overview
Transaction SOLUTION_MANAGER is the central access point for all operation scenarios in the SAP Solution Manager © SAP AG 2007
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-99
Assignment of Logical Components to the Solution 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.
Choose node .
Assign logical components in tab “System Group” via value help.
© SAP AG 2007
In the node 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-100
Assignment of Business Processes in the Solution Directory
© SAP AG 2007
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-101
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 Elements Create Change Requests for a Solution
© SAP AG 2007
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-102
Scenario Checked Out
© SAP AG 2007
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-103
Solution Manager Unit Overview Diagram SAP Solution Manager Introduction Lesson 1: Solution Manager System Landscape (SMSY) Lesson 2: System Landscape Directory Lesson 3: Solutions Lesson 4: Projects Lesson 5: Business Processes
© SAP AG 2007
© SAP AG
E2E200
2-104
SAP Solution Manager Architecture SAP Solution Manager Roadmap, Blueprint and Implementation Change Diagnostics
Maintenance Optimizer
Testing
P
je ro
ct
s
tio lu o S
Application Management
n Service Desk
Change Request Management
BPR
Implementation Content
Business Processes
Documentation Systems
SAP ERP
NW BI
NW XI
Solution Directory
Other
© SAP AG 2007
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-105
Solution Manager Projects Projects: Projects focus on managing changes All implementation scenarios in SAP Solution Manager are based on projects: Implementation Testing Upgrade E-Learning Management
Any project change is copied to the solution directory after being set active Handover to Operation
Projects work not only in the production landscape, but in the complete transport landscapce including the following system types: Evaluation Development Quality Assurance …
© SAP AG 2007
© SAP AG
E2E200
2-106
Scope of Projects Project Phases Realization
Final Preparation
Go Live
Solution Project Landscape
Gobal ERP
Gobal ERP
Gobal ERP
Global CRM
Global CRM
Global CRM
Global BW
Global BW
Global BW
Development
Quality Assurance
Production
© SAP AG 2007
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-107
Lifecylce Management is performed within Projects
Implementation Project
Solution 1
Maintenance Project
Implementation Solution 1
Upgrade Project
Operation
Solution 2
Template Project
Implementation Implementation Project Project
Upgrade Rollout
Solution 3a Solution 3b
© SAP AG 2007
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-108
General Project Administration
General project administration functions: Transaction SOLAR_PROJECT_ADMIN Create projects Change projects Display projects Delete projects Transport projects Direct access to project templates
© SAP AG 2007
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-109
Define Project – General Data
Define general project data: Person responsible for the project Language of the project: determines in which language the selected business content is displayed and stored Overall project status Project time frame for plan and actual data
© SAP AG 2007
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-110
Assign Logical Components
Define system landscape for a project: Select product and product version Assign development, quality assurance and productive systems to products Check related system landscape
© SAP AG 2007
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-111
Solution Manager Unit Overview Diagram SAP Solution Manager Introduction Lesson 1: Solution Manager System Landscape (SMSY) Lesson 2: System Landscape Directory Lesson 3: Solutions Lesson 4: Projects Lesson 5: Business Processes
© SAP AG 2007
© SAP AG
E2E200
2-112
Business Processes in SAP Solution Manager Scenario Component View Business Process 1
Process Step 1
VISUALIZE flow of business processes
and process steps Process Step 2 ...
Show components required by
business scenario or process Show business partners or external
Business Process 2
software required by the business scenario or process CRM MOBI LE C LIENT
CRM S ERV ER
S AP S EM
Create Cam paig n
Updat e the C am paig n Hier arc hy
Refere nce t o B usin ess Pro cess: Tar get Gr oup Cre ation
Load Cam paig n Attrib utes
SAP R/3
Perfor m Ma rket An alysis
Process Step 1
Create Collat era ls
Allocate t o cam paig n
P lan Key Figu res
Updat e the K ey Fi gur es for the Camp aign
P lan A llocati ons
...
Load All ocati ons Tra nsfer Cam paig n, T arg et Gr oup, P roducts, Att ach ments, A ll oc. to Mobile
Releas e Ca mpai gn
Tra nsfer Cam paig n
Tra nsfer Acti vities to CRM Mobil e
Create Accou nting Object (WBS ) Post Direct Mark etin g Costs t o Accountin g Obj ect (WBS)
Tra nsfer Ta rget Gro ups
Settle Dir ect Ma rketi ng Co sts to Profitabilit y Seg ment Updat e Direc t Ma rketin g Cost s Info
Execute C amp aign
Updat e Activities I nfo
Load Cost Dr ivers Refere nce t o B usin ess Pro cess: Lead P roces sing
Refere nce t o Busin ess Pro cess: Custom er V isit a nd O rde r Entry
Scenario-oriented structure
Assess Over hea d Cost s to WBS Element
Refere nce t o B usin ess Pro cess: Order P roces s in B2B eS ellin g
Updat e Over hea d Cost s Info
Refere nce t o B usin ess Pro cess: Order P roces s in B2C eSellin g
Perfor m Cam pai gn Ana lysis
(= Business Process Hierarchy) © SAP AG 2007
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-113
Business Process Structure
Documentation linked to business process steps
© SAP AG 2007
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-114
Copy Business Processes from Project to Solution For each business scenario, create the respective business processes. Choose / Business Scenarios / / Business Processes in the tree and create the business processes in tab “Structure”.
Set status to “Production”. Create business processes.
© SAP AG 2007
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-115
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 2007
© SAP AG
E2E200
2-116
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.com Forum SAP Solutions SAP Solution Manager
© SAP AG 2007
© SAP AG
E2E200
2-117
Exercises Unit: Lesson:
Solution Landscape Documentation 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:
2-1-2
Answer: ______________________________________________ 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-118
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-119
Exercises Unit: Lesson:
Solution Landscape Documentation 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 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-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?
2-2-4
Answer: ______________________________________________ What is the lastest Support Package available for this component?
2- 2-5
Answer: ______________________________________________ Where does the information on the latest Support Package come from?
2-2-6
Answer: ______________________________________________ Is a business system defined?
© SAP AG
E2E200
2-120
© SAP AG
E2E200
2-121
Exercises Unit: Lesson:
Solution Landscape Documentation 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-122
© SAP AG
E2E200
2-123
Exercises Unit: Lesson:
Solution Landscape Documentation 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-124
© SAP AG
E2E200
2-125
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-126
© SAP AG
E2E200
2-127
Solutions Unit: Lesson:
2-1
Solution Landscape Documentation Solution Manager System Landscape
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:
2-1-2
The transaction name is SMSY 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?
2-1-3
check the value for Last Changed On/By 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-128
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-129
© SAP AG
E2E200
2-130
Solutions Unit: Lesson:
2-2
Solution Landscape Documentation System Landscape Directory
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://:/sld and provide a username and password in order to logon to the SLD. The default port is 500. 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-131
© SAP AG
E2E200
2-132
Solutions Unit: Lesson:
2-3
Solution Landscape Documentation Solutions
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-133
© SAP AG
E2E200
2-134
Solutions Unit: Lesson:
2-4
Solution Landscape Documentation Projects
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-135
© SAP AG
E2E200
2-136
Solutions Unit: Lesson:
2-5
Solution Landscape Documentation Business Processes
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-137
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:
2-5-6
2-5-7
© SAP AG
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. 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 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.
E2E200
2-138
E2E Change Diagnostics
Introduction to E2E Change Control Management Solution Landscape Documentation E2E Change Diagnostics Netweaver Development Environments Enhanced Change and Transport System Transport Strategies Change Request Management Maintenance Management Test Management IT Reporting for Change Control © SAP AG 2007
© SAP AG
E2E200
3-139
E2E Change Diagnostics Contents: Configuration and File Reporting E2E Change Analysis
© SAP AG 2007
© SAP AG
E2E200
3-140
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 solutions
including: Technical Configuration Business Configuration Content (EP, XI, BI, SLD, …) Coding
Compare Technical Configuration between
landscapes
© SAP AG 2007
© SAP AG
E2E200
3-141
Change Diagnostics – Typical Questions
How many transports were imported last week? Did we change any technical configuration parameters?
When did we import support packages?
Is there ONE place where all changes in the solution are listed
Did we change anything last Tuesday?
© SAP AG 2007
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-142
E2E Change Diagnostics: Overview E2E Change Analysis Tools Configuration Tracking
Type of changes
Technical Configuration
Enhanced Change and Transport System
Patches, SP, Release
Business Configuration
“Content” EP, XI, BI, SLD
Coding
Changes to Production Productive Environment Documented in SAP Solution Manager (SMSY)
© SAP AG 2007
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-143
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
changes Providing hints for root cause analysis with data and trends Providing accurate information on configuration parameters and
their history (e.g. database parameters, ABAP parameters, JAVA parameters) Enabling the organization to standardize the solution
configuration Improving security by controlling the versions of configurations
in use
© SAP AG 2007
© SAP AG
E2E200
3-144
E2E Change Diagnostics Unit Overview Diagram E2E Change Diagnostics Lesson 1: Configuration and File Reporting Lesson 2: E2E Change Analysis
© SAP AG 2007
© SAP AG
E2E200
3-145
Architecture of a J2EE System Landscape Agent
Web AS Instance
Agent
D S
Agent
S
S
Web AS Instance
Agent
S
S
Agent
S
Web AS Instance
S
S
S
Agent
S
Web AS Instance
S
Agent
S
S
S
Web AS Instance
S
Production
S
S
S
Agent
S
QA S
S
Config store
Web AS Instance D
S
SAP Solution Manager
Web AS Instance D
D S
Web AS Instance D
D
D S
Agent
D
D S
Web AS Instance
S
Development S
© SAP AG 2007
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-146
View Configuration Data
© SAP AG 2007
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-147
Compare two Landscapes
1.Click
3.Click
2.Click
Result
© SAP AG 2007
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-148
Compare two Landscapes - Result Unchanged value Different value Additional value Missing value
© SAP AG 2007
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-149
Compare Multiple Instances
Missing value
Additional value
Unchanged value Different value Additional value Missing value
© SAP AG 2007
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-150
The parameter changes (different value, missing value, unchanged value and additional value ) are marked with different icons
© SAP AG
E2E200
3-151
E2E Change Diagnostics Unit Overview Diagram E2E Change Diagnostics Lesson 1: Configuration and File Reporting Lesson 2: E2E Change Analysis
© SAP AG 2007
© SAP AG
E2E200
3-152
Configuration and File Reporting - Architecture
Data collection once a day
Diagnostics Diagnostics agents agents Solution Manager Java-based Java-based installations installations
Config store
Parameter values
Configuration and file reporting © SAP AG 2007
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-153
E2E Change Analysis - Architecture E2E change analysis
Number of changes
InfoCube
Data collection once a day
Data collection once a day
Diagnostics Diagnostics agents agents
Solution Solution tool tool plug-ins plug-ins Solution Manager
Java-based Java-based installations installations
Config store
ABAP-based ABAP-based installations installations
Parameter values
Configuration and file reporting © SAP AG 2007
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
Change Groups and Change Types ABAP Software Version
Operation System
ABAP Component Release
OS Parameter
ABAP Packages
OS Level
Support Package Level
OS Patch Level
SAP Notes SAP Kernel
Database DB Parameter
JAVA Software Version
DB Level
JAVA Component Release JAVA Support Packages Fixes
DB Patch Level
ABAP System Configuration ABAP Instance Parameter
Patches
RFC Destinations
Transports Workbench
JAVA System Configuration JAVA Instance Parameter
Customizing Non-ABAP
BI, SCM, CRM, XI, …
© SAP AG 2007
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-155
Example: Data Source for ABAP Parameter
© SAP AG 2007
The table PAHI is the data source for the ABAP parameter
© SAP AG
E2E200
3-156
Different Types of Data
Type of Data
Data Collection Method
Detail Viewer
Technical Snapshot Details Snapshot Method Method Technical Configuration Configuration Details available available OS, OS, DB, DB, ABAP ABAP parameters parameters Daily Daily snapshot snapshot is is transferred transferred Number Number of of changes changes is is to displayed to E2E E2E Change Change Analysis Analysis displayed in in the the overview overview Full configuration Full configuration set set can can be be displayed displayed for for each each day day Transports Timestamp Details Details not not available available Transports and and Patches Patches Timestamp Method Method Patches, Patches, SP, SP, Release Release Number Number of of events events since since last last Number Number of of events events is is data collection run is displayed in the overview Business Configuration Business Configuration data collection run is displayed in the overview transferred Content Content (EP, (EP, XI, XI, BI, BI, SLD) SLD) Detail Detail information information is is located located transferred to to E2E E2E Change Change Analysis in in the the managed managed systems systems Analysis Coding Coding
© SAP AG 2007
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-157
Data Extraction Process E2E Change Analysis
BI
Other Infocubes
ST E2E Change Analysis MainExtractor DAILY
E2E MainExtractor HOURLY
„Configuration Changes“
„Change Events“
E2E Extraction Framework
E2E Extraction Framework
Configuration Store (SMD DB) SMD
SMD Scheduler Configuration Collector (Wrapper)
Java System Java System Java System
ABAP System ABAP System ABAP System
ABAP / JAVA ABAP / JAVA System ABAP / JAVA System System
© SAP AG 2007
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-158
Required Software Versions
Release
Support Package
Planned Availability
NW04s
SPS13
August 2007
Solution Manager
SP13
August 2007
BI_Cont
SP6
July 2007
ST-A/PI
01J_CRM500
May 2007
© SAP AG 2007
© SAP AG
E2E200
3-159
System Demonstration
System-Demo
© SAP AG 2007
© SAP AG
E2E200
3-160
E2E Change Analysis - Overview
BSO
B70
© SAP AG 2007
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-161
E2E Change Analysis – Query Navigation
© SAP AG 2007
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-162
Detail viewer per change type and change day
For the details, jump into the config stores, displaying the parameter for the selected system and calendar day © SAP AG 2007
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-163
End to End Change Diagnostics: Unit Summary You should now be able to: Look up recent changes in the customer solutions
including: Technical Configuration Business Configuration Content (EP, XI, BI, SLD, …) Coding Compare Technical Configuration between
landscapes
© SAP AG 2007
© SAP AG
E2E200
3-164
© SAP AG
E2E200
3-165
Exercises Unit: Lesson:
E2E Change Diagnostics 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-166
Answer: ______________________________________________
© SAP AG
E2E200
3-167
3-1-6 3-1-7
© SAP AG
Compare the complete configuration for the ESS Solution solution with an older version. Perform a Deep Compare for the ConfigStores Path = DVEBMGS50/j2ee/
E2E200
3-168
Exercises Unit: Lesson:
E2E Change Diagnostics 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-169
3-2-5
3-2-6
© SAP AG
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: _________________________________________________ Drill down into the configuration details for the latest Java parameter changes. Which parameters were changed on that day? Answer: _________________________________________________ ________________________________________________________ ________________________________________________________ ________________________________________________________ ________________________________________________________ ________________________________________________________
E2E200
3-170
Solutions Unit: Lesson:
3-1
E2E Change Diagnostics Configuration and File Reporting
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://:50000/smd 3-1-2 Call the Configuration and File Reporting tool. What is the path?
3-1-3
3-1-4
Root Cause Analysis Configuration Configuration and File Reporting 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. 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?
3-1-5
Check the Date entry in the end of the line for the ConfigStore name. 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-171
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-172
3-1-6
3-1-7
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. 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-173
Solutions Unit: Lesson:
3-2
E2E Change Diagnostics E2E Change Analysis
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-174
3-2-6
© SAP AG
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. 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.
E2E200
3-175
NetWeaver Development Environments
Introduction to E2E Change Control Management Solution Landscape Documentation E2E Change Diagnostics NetWeaver Development Environments Enhanced Change and Transport System Transport Strategies Change Request Management Maintenance Management Test Management IT Reporting for Change Control © SAP AG 2007
© SAP AG
E2E200
4-176
NetWeaver Development Environments Contents: ABAP Development Workbench NetWeaver Development Infrastructure Enterprise Portal Exchange Infrastructure Software Deployment Manager
© SAP AG 2007
© SAP AG
E2E200
4-177
NetWeaver Development Environments: Unit Objectives At the end of this unit, you will be able to: Describe the different development environments,
which are integrated in SAP NetWeaver ABAP Development Workbench NetWeaver Development Infrastructure and its
components Enterprise Portal Content Administrator Exchange Infrastructure Integration Builder Explain the functions of the Software Deployment
Manager
© SAP AG 2007
© SAP AG
E2E200
4-178
Manage Heterogeneous Development Environments ABAP Development Workbench NetWeaver Development Infrastructure
ABAP Change & Transport System
Development Landscape ck i ch e
Transport
Quality Landscape
Transport
Production Landscape
n Deploy
EPA
Enterprise Portal Content Administrator
Deploy
Software Deployment Manager
Software Deployment Manager
Quality Component 1
Production Component 1
. .
. .
Quality Component n
Production Component n
TPZ
Exchange Infrastructure Integration Builder … (open Interface for non-ABAP objects)
© SAP AG 2007
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-179
NetWeaver Development Environments Unit Overview Diagram NetWeaver Development Environments 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 2007
© SAP AG
E2E200
4-180
Data Types in SAP Systems Customizing
#
data
Customizing
Appl. data
…. Customizing
User
Appl. User
# Customizing Customizing
#
Cross-client Customizing
SAP Repository
Development Modifications
Customer Enhancements
© SAP AG 2007
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 clientindependent 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-181
Integrated ABAP Development Workbench
© SAP AG 2007
Transaction SE80 is the integrated ABAP development workbench. All repository objects can be changed here.
© SAP AG
E2E200
4-182
SAP Implementation Guide for Customizing
© SAP AG 2007
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-183
Automatic Recording of Changes Implementation Guide (IMG)
ABAP Development Workbench ABAP Development Workbench
Cost cent er Edit Goto D etails E nviro nme nt Syste m Hel p ??
Object Browser
Global Settings Countries Currencies Calendars
Customizing Organizer
DEVK900125 DEVK900126
ABAP Editor
Function Library
Screen Painter
Menu Painter
Workbench Organizer Transportable
Customizing DEVK900124
ABAP Dictionary
DEVK900131
Change Request Task Task
DEVK900133 DEVK900134
Change Request Task Task
ABAP Program Source ZCDEMO ZCACTION
View Maintenance: Data V_TVAK V_TSPA
Transport Management System
© SAP AG 2007
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-184
Customizing Organizer and Workbench Organizer
Customizing Organizer - SE10
Workbench Organizer - SE09
Customizing
Development
Change documentation
Change documentation
Teamwork
Teamwork
Table change history
SSCR
(logging)
Packages Object locking
Connected to Client
Version management
Administration and Transport Management System
Connected to Transport
Management System
© SAP AG 2007
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-185
NetWeaver Development Environments Unit Overview Diagram NetWeaver Development Environments 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 2006
© SAP AG
E2E200
4-186
NetWeaver Development Infrastructure: Learning from ABAP Logon to SAP development system
Defines the whole environment of own and foreign components
logon to NWDI DevConfig
copy & checkout source files, change development objects
check-out & change development objects
Correct libraries are copied automatically
Implicit check for formal correctness
activate changes
visibility for everyone
build centrally & activate changes
early integration
test application
ABAP
Developer tests within the central environment
release transport
test application
release for transport
JAVA
© SAP AG 2007
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-187
Building Blocks of NWDI Central Infrastructure
Design Time Repository (DTR)
Component Model
Local File System
Local Build Tool
Local SAP Web AS Java
Name Service
Java Runtime Environment for the SAP Systems (DEV,CONS, ...)
Component Build Service (CBS)
Deployment
Development environment (IDE)
Runtime Systems
Change Management Service (CMS)
Local Installation on Developer's PC
System Landscape Directory (SLD)
© SAP AG 2007
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-188
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-189
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 2007
© SAP AG
E2E200
4-190
Product. & SCs define
Track & Dev. Configs.
ADMINISTRATION / QM
DEVELOPMENT
ADMINISTRATION
Development Cycle Using NWDI – Overview
import
Development
1. 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 landscape Define a track for the specific release of the SC Development 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
release
SL Change Mgmt. prepare
Delivery define
Next Release
by importing the corresponding development configuration Release objects for further processing by QM
4. CMS: Perform further administrative steps Transport into next dev. steps, quality assurance,
and assembly using the Change Management Service
5. CMS: Deliver SCs and patches Deliver software component versions
6. CMS: For the next release define new versions
© SAP AG 2007
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-191
Transports Within a Track – Overview Netweaver Development Infrastructure Development Configuration
Development Configuration
A Change Requests
Workspaces Workspaces
B
C
Workspaces Workspaces
1
2
Software Component Archive (SCA)
3
Version i
Buildspace
Buildspace
Central Development System
Consolidation System
Developer: Entwickler A CheckIn
Test system
Production System
Administrator: 1 Import
B Activate
2 Assembly & Import
C Release
3 Approval & Import
© SAP AG 2007
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-192
(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-193
Component Model in Delivery And Maintenance
Products
P1
P2
Release
Software Components
S1
S2
Support Package
Development Components
D6
D11
(Fix) D4
Objects
D8
O1
O2
D5
D7
D9
D10
O3
© SAP AG 2007
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-194
Structuring Applications Using the Component Model Product X
SC B (imported, read only)
uses
SC A (imported, read only)
uses
consists of
SLD
SC X (changeable)
CMS
SAP NW Dev. Studio
DC
DC
DC
DC
DC
DC DC
DC DC DC
DC
© SAP AG 2006
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-195
- 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-196
Source Code Management in the DTR – Basics Distributed, concurrent development Distributed versioning that spans repositories Conflict detection Support for conflict resolution
Files and Folders DTR knows only files and folders No knowledge about objects of programming model (classes, tables, screens etc)
Check in/check out model Files are checked out from DTR and modified “offline” Files are checked in again when change is complete
© SAP AG 2006
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-197
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 Eclipsebased 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-198
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-199
Design Time Repository – Modification Adjustment
WSSAP
Scenario: The same file was changed in two workspaces concurrently Propagation of changes from one workspace to another integration conflict
WScust
Install
a1
a1
Distributed versioning and conflict resolution: Apply SP
a2 conflict
a2
Changes are recognized as
b1
versions of same file Imported versions are correctly placed in version graph No risk of overwriting changes in target repository
b2
Accept / reject or merge integrated version © SAP AG 2007
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-200
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-201
Component Build Service (CBS) Act.d edit VR d
DTR
activate
CBS
inactive workspace
DC 2 a b
c
d
Temporary Folder DC 2
DC 1
DC 1 Archives
DC 2
DC 2 Archives
DC 3
DC 3 Archives
DC 4
DC 4 Archives
d Build c a b
c
d
DC 2
b
DC 5 Archives
a
DC n Archives
Buildspace
active workspace
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. © SAP AG 2007
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-202
CMS
Component Build Service
Design Time Repository
Transport Studio
Landscape Configurator
NWDI – Scenario Overview
Process Integrat.
Dev. Studio
NWDI
Pure Source Control
Enterprise Portal Custom Development
Modification Mgmnt
© SAP AG 2007
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 nwhowtoguides). 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-203
•
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-204
NetWeaver Development Environments Unit Overview Diagram NetWeaver Development Environments 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 2007
© SAP AG
E2E200
4-205
Visible Portal Objects
Page Top-level Navigation iView
Detailed Navigation iView
© SAP AG 2007
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-206
Portal Content Directory (PCD) Objects Role:
Role Navigation Page 1 workset 1
Page 2
workset 2
iView 1 iView 2 iView 3
workset 3
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. •
iView 1 iView 2
workset 2.1
workset 2.2
iView 1 iView 2
iView 1 iView 2
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.
The Enterprise Portal provides a role-based user interface © SAP AG 2007
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-207
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-208
Packaging Model – Packaging Portal Transport Archives Scenario A: Import and Export EPA-Files including PAR-Files via Portal Import/Export Tool You want to import and export portal content objects and include depending par-files (like EP6.0 SP2).
Scenario B: Import and Export EPA-Files without PAR-Files via Portal Import Export Tool You 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 SDM You 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. © SAP AG 2007
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-209
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-210
PCD Objects – The Export Function This tool is used to export any type of PCD Object except for “Themes”.
Using the property Pcd.TransportApplication.ProtectedNamespaces in the file global/config/pcd/pcdStartup.template.properties namespaces can be generally excluded from exportation. In addition, while exporting a transport
package, you can decide to export only name spaces of your choice.
© SAP AG 2007
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-211
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 2007
© SAP AG
E2E200
4-212
SAP Enterprise Portal File Types SAP NetWeaver Packaging Model Development
Represents a
SCA
Component
Represents a
Software entity with own life cycle
SDA
Development Component
EAP
Single deployable archive
EAR Runtime-internal sub-archives
Development
EPT
PAR
Component
WDA … SCA – Software Component Archive SDA – Software Deployment Archive EPA – Enterprise Portal Archive EPT – Enterprise Portal Transport PAR – Portal Archive EAR – Enterprise Application Archive WDA – Web Dynpro Application
© SAP AG 2007
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-213
NetWeaver Development Environments Unit Overview Diagram NetWeaver Development Environments 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 2007
© SAP AG
E2E200
4-214
PI Component Overview Shared Collaboration Knowledge
Execution of Collaborative Business Processes
Integration Builder
Central Monitoring SAP Systems
Integration Repository (IR)
Integration Directory (ID)
Integration Server (IS)
3rd Party Systems 3rd Party Middleware Component Marketplace/ Business Partner
System Landscape Directory (SLD)
© SAP AG 2007
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-215
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-216
Integration Builder – Design Time Integration Builder Integration Repository Scenario Editor
Business Scenarios
Process Editor
Business Processes
BPEL
Mapping Editor
Mappings
XSLT Java
Condition Editor
Context Objects
XPath
Message Interfaces
WSDL
Interface Editor
Proxies
Message Types Data Types
J2EE/ABAP
XSD
SAP Web AS ≥ 6.20
Software Component Version
Software Component
System Landscape Directory © SAP AG 2007
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-217
Integration Builder – Generic Functions Integration Repository
Integration Directory
UI Client
Layout Building Blocks Personalization Navigation Integration Builder Client Framework
Server
Query Service & Cross References Import/Export & CMS interface Internationalization Change list Management Versioning Locking Authorization & Authentication Integration Builder Server Framework
DB
© SAP AG 2007
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-218
Integration Builder – Configuration Time Integration Builder Integration Directory Scenarios Business Processes Configuration Wizards
Routing Rules Receiver Determination Rules Interface Determination Rules (including Mapping Assignment)
Configuration Editors
Collaboration Agreements Security
Collaboration Profiles Parties & Services Channels
© SAP AG 2007
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-219
Transport of PI Objects via Export/Import Integration Repository Objects: Integration Scenario Action Integration Process Message Interface Message Type Fault Message Type Data Type Data Type Enhancement External Definition Context Object Interface Mapping Message Mapping Mapping Template Imported Archive Adapter Metadata Communication Channel Template Function Module ABAP Dictionary Type IDoc IDoc Message Type IDoc Type IDoc Segment IDoc Extension
© SAP AG 2007
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-220
Import of PI Objects After exporting, we can locate the file in the following folder on the source PI server: …\usr\sap\\SYS\global\xi\r epository_server\export
Copy the .tpz file to the target PI server in the following folder: …\usr\sap\\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\\SYS\global\xi\repository_server\ import\importedFiles
© SAP AG 2007
© SAP AG
E2E200
4-221
Transport of PI objects via NWDI (CMS) With NWDI PI, transports can be managed centrally in these tracks Productive
Consolidate
SAP NetWeaver
SAP NetWeaver
Usage Type PI
Usage Type PI
Usage Type PI
Repository
Repository
• SC version • Data Types • Message T. • ... • SC version
• SC version • Data Types • Message T. • ... • SC version
• SC version • Data Types • Message T. • ... • SC version
Directory
Directory
Directory
• Business Scenario • Party • Services •…
• Business Scenario • Party • Services •…
• Business Scenario • Party • Services •…
DTR
Transport Studio
Landscape Configurator
CBS
CMS
Repository
SLD
With NWDI used PI systems are set in tracks
SAP NetWeaver
Change Management Service
PI-Track Y Directory PI-Track X Repository
SC X (Definition) Names (reserv.)
SAP NetWeaver © SAP AG 2007
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-222
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
© SAP AG 2007
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-223
Activity Sequence when transporting PI objects Maintain the groups and transport targets in the System
Landscape Directory Export the Integration Repository Export the Integration Directory Export and import the System Landscape Directory (only in the case of multiple SLDs) Copy the exports from the source host directory to the target host Import the Integration Repository Import the Integration Directory Rework data in the Integration Directory (end points and logon data) Activate distribution in Directory
© SAP AG 2007
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-224
NetWeaver Development Environments Unit Overview Diagram NetWeaver Development Environments 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 2007
© SAP AG
E2E200
4-225
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 software
components on the J2EE Engine. If needed the SDM controls the restart of the satellite system during 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 2007
© SAP AG
E2E200
4-226
SDM Repository
© SAP AG 2007
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-227
Deployment of new Archives
The SDM Interface appears. 1) Click on the Deployment tab
© SAP AG 2007
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-228
Undeployment
© SAP AG 2007
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-229
Dependency Graph
© SAP AG 2007
In the SDM repository, right-click the component and choose “Show Dependency Graph”.
© SAP AG
E2E200
4-230
Log Viewer
© SAP AG 2007
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-231
NetWeaver Development Environments: Unit Summary You should now be able to: Describe the different development environments
integrated in SAP NetWeaver ABAP Development Workbench NetWeaver Development Infrastructure and its
components Enterprise Portal Content Administrator Exchange Infrastructure Integration Builder
Explain the functions of the Software Deployment
Manager
© SAP AG 2007
© SAP AG
E2E200
4-232
© SAP AG
E2E200
4-233
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-234
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-235
Solutions Unit:
4-1
Netweaver Development Environments
Which following component is not part of NWDI but required by NWDI? Please choose the correct answer.
4-2
O
Change Management Service (CMS)
X
System Landscape Direcory (SLD)
O
Design Time Repository (DTR)
O
Component Build Service (CBS)
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-236
© SAP AG
E2E200
4-237
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
4-238
Enhanced Change and Transport System
Introduction to E2E Change Control Management Solution Landscape Documentation E2E Change Diagnostics NetWeaver Development Environments Enhanced Change and Transport System Transport Strategies Change Request Management Maintenance Management Test Management IT Reporting for Change Control © SAP AG 2007
© SAP AG
E2E200
5-239
Enhanced Change and Transport System Contents: Transport of non-ABAP Objects Configuration Process Flow Tracking of Changes Benefits of Change Request Management
© SAP AG 2007
© SAP AG
E2E200
5-240
Enhanced Change and Transport System: Unit Objectives At the end of this unit, you will be able to: Explain the concept of transporting Non-ABAP
objects with the Enhanced Change and Transport System Track changes in JAVA systems Know how Change Request Management supports
changes of non-ABAP objects
© SAP AG 2007
© SAP AG
E2E200
5-241
Enhanced Change and Transport System Unit Overview Diagram Enhanced Change and Transport System 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 2007
© SAP AG
E2E200
5-242
Motivation to Extend the Change and Transport System
Change and Transport System (CTS) and NetWeaver Development Infrastructure provide powerful functions to control transports in ABAP and JAVA. What was missing? Synchronized import into double stack systems A solution for the transport of Portal content A central administration interface for all types of transports
and systems Tracking and management of Non-ABAP objects with Change Request Management
The open issues are addressed with the Enhanced Change and Transport System
© SAP AG 2007
© SAP AG
E2E200
5-243
Enhanced Change and Transport System (CTS+)
Connect Java Systems to standard CTS Non-ABAP applications inherit all properties of the ABAP
Change and Transport System in terms of documentation, tracking and troubleshooting features Manages transport of ABAP and non-ABAP-objects centrally Allows combined transports for mixed objects (ABAP, JAVA, …) Allows synchronized changes to business processes which
run in ABAP and JAVA 100% Compatible with SAP Solution Manager No need to upgrade of Java landscapes
© SAP AG 2007
© SAP AG
E2E200
5-244
Manage Heterogeneous Development Environments Change and Transport System
ABAP Workbench SE80 Exchange Infrastructure Integration Builder
Development Landscape check
Transport
in
Transport
Production Landscape
Deploy
SCA
Developer Studio and NWDI
Quality Landscape
EPA
Enterprise Portal Content Administrator
Deploy
Quality Component 1
Production Component 1
. . .
. . .
Quality Component n
Production Component n
… (open Interface for non-ABAP objects) © SAP AG 2007
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-245
Supported Solutions and Deployment Options
Transport of: Enterprise Portal
objects (EPA, PAR) Objects from NWDI (SCAs,…) Objects from XI Interface for NonSAP applications
Deployment Options: SDM XI FS
© SAP AG 2007
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-246
Enhanced Change and Transport System Unit Overview Diagram Enhanced Change and Transport System 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 2007
© SAP AG
E2E200
5-247
Transporting Non-ABAP Changes ABAP Transport Controller
Virtual QAS
Virtual PRD
Legend logical transport route of non-ABAP objects physical transport route of non-ABAP objects
Java DEV
Java QAS
Java PRD
Non-ABAP
Non-ABAP
Non-ABAP
check-in/check-out of non-ABAP objects transport route of ABAP objects
SAP NetWeaver Application Server CTS+
Transport parameter contain deploy options New System Type: Virtual Non-ABAP System
© SAP AG 2007
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 AfterImport Method, the Java Archives are deployed via Software Deployment Manager
© SAP AG
E2E200
5-248
Java Stack: Example EP (or XI Java Stack)
NW04s = SPS12 CTS+ Transport Controller ABAP
CTS+
Java
Deploy Service
2 Import
3 1
Upload of Archive
Virtual QAS
Import
Virtual PRD
TP calls Deploy Service
4
Deploy in EP QA System via SDM
EP
EP
EP
Dev. System
QA System
Prod. System
Java
DevEnv
NW04s < SPS12
Java
DevEnv
NW04s < SPS12
Java
DevEnv
NW04s < SPS12
© SAP AG 2007
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-249
Double Stack Installation: Example XI XI
XI
Transport Route
Source System
Target System Transport Request
ABAP stack Java stack
ABAP stack Java stack
ABAP Objects Java Objects
XI
XI
XI
Dev. System
QA System
Prod. System
CTS+
ABAP Java
IB
Deploy Service
NW04s = SPS12
Transport
ABAP Java IB
CTS+ Deploy Service
NW04s = SPS12
Transport
CTS+
ABAP Java
IB
Deploy Service
NW04s = SPS12
© SAP AG 2007
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-250
STMS Configuration in the Transport Controller
© SAP AG 2007
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-251
Transport Parameters for the Virtual Non-ABAP Systems
EP System
XI System
© SAP AG 2007
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-252
Enhanced Change and Transport System Unit Overview Diagram Enhanced Change and Transport System 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 2007
© SAP AG
E2E200
5-253
Enhanced Change and Transport System Process ABAP Transport Controller
Web Interface to Transport Organizer
Portal - DEV Create content
Create Transport Request
Assign archive to transport request
Release Transport Request
Virtual QAS
Import
Virtual PRD
Import
Web Service for Deployment Deploy
Web Service for Deployment Deploy
Export Java Archive Call Web Service (Close Coupling)
Portal - QAS
Deploy
Portal - PRD
Deploy
© SAP AG 2007
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 nonABAP 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-254
Create Transport Request
© SAP AG 2007
The first step is to create a transport request in the Transport Controller
© SAP AG
E2E200
5-255
Export Java Archive
© SAP AG 2007
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-256
Web Interface to the Transport Organizer
Assign Objects to Transport Requests and Release Request
© SAP AG 2007
In the CTS Adapter Web Service you can attach Non-ABAP objects to transport requests and release the transport request
© SAP AG
E2E200
5-257
Import Request in Virtual Non-ABAP System
© SAP AG 2007
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-258
ABAP Transport Landscape vs. CMS Track (NWDI) TMS: 3-System-Landscape Change Requests
DEV System ABAP System
Consolidation
SAP NetWeaver - Development ABAP Stack
Java Stack
System Runtime
Change Requests
QA System
PROD System
Delivery
ABAP System
SAP NetWeaver – Quality Assurance
SAP NetWeaver - Production
Java Stack
ABAP Stack System
Runtime
Build Env.
ABAP System
ABAP Stack
Java Stack
System
Runtime
Runtime
Build Env.
Runtime
Runtime
Build Env.
Repository
Repository
Repository
Workbench
Workbench
Workbench
CMS: Track „QA System“ DEV System
CONS System CONS System Runtime System
Runtime System Development Configuration
Change Requests
Development Configuration
assembly
TEST System
PROD System
Runtime System SCA
Runtime System SCA
© SAP AG 2007
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-259
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-260
Synchronization of ABAP and Java Transports TMS: 3-System-Landscape Change Requests
DEV System
Change Requests
QA System ABAP System
ABAP System
SCA
PROD System PROD System ABAP System
SCA
Java Runtime
Java Runtime
SAP NetWeaver - Development ABAP Stack
deployment is triggered by tp import SAP NetWeaver - Production SAP NetWeaver – Quality Assurance
Java Stack
ABAP Stack
Runtime
Runtime
System Runtime
ABAP Stack
System
System Runtime
Runtime
Build Env.
Build Env.
Build Env.
Repository
Repository
Repository
Workbench
Workbench
Java Stack
Workbench
Runtime
Java Stack
CMS: Track DEV System
check-in to ABAP change request
Runtime System
CONS System CONS System Runtime System
Development Configuration
Development Configuration
SCA
assembly © SAP AG 2007
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-261
• 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-262
Enhanced Change and Transport System Unit Overview Diagram Enhanced Change and Transport System 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 2007
© SAP AG
E2E200
5-263
Tracking of Changes Use the Import History to find information on transports in Non-ABAP systems: Object Lists Transport Logfiles
The Import History can be accessed from any system in the Transport Domain
© SAP AG 2007
© SAP AG
E2E200
5-264
Import History of Non-ABAP System
© SAP AG 2007
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 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-265
Navigate through the Object List
© SAP AG 2007
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-266
Navigate through the Transport Logfiles
© SAP AG 2007
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-267
Enhanced Change and Transport System Unit Overview Diagram Enhanced Change and Transport System 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 2007
© SAP AG
E2E200
5-268
Different Levels of Control Change Request Management SAP Solution Manager Improved Documentation
Better Control
Enhanced Change and Transport System (CTS+)
SAP System ABAP Stack Improved Documentation
ABAP
Better Control
Java
.net
…..
© SAP AG 2007
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-269
Change Request Management in a Mixed ABAP/JAVA Landscape Development Landscape Development Environment
System
QA Landscape
Production Landscape
System
System
Transport Landscape ERP
SE80 DS & DI
mySAP ERP
mySAP ERP
mySAP ERP
Transport Landscape CRM
SE80 DS & DI
mySAP CRM
mySAP CRM
mySAP CRM
Transport Landscape EP
Portal Content Administrator DS & DI
Enterprise Portal
Enterprise Portal
Enterprise Portal
Transport Landscape BW
SE80
BW
BW
BW
Transport Landscape PI
SE80 Integration Builder
Process Integration (XI)
Process Integration (XI)
Process Integration (XI)
Change Request Management
SAP Solution Manager © SAP AG 2007
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-270
Enhanced Change and Transport System: Unit Summary You should now be able to: Explain the concept of transporting Non-ABAP
objects with the Enhanced Change and Transport System Track changes in JAVA systems Know how Change Request Management supports
changes of Non-ABAP objects
© SAP AG 2007
© SAP AG
E2E200
5-271
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.
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: ______________________________________
5-1
© SAP AG
E2E200
5-272
5-1-9
© SAP AG
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.
E2E200
5-273
Solutions Unit:
5-1
Enhanced Change and Transport System
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://: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-274
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
5-1-5
and import it with the Import Request button ( ). Check in the transport log files if the import was successful.
5-1-6
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. Check in the object list for the name of the Java archive.
5-1-7 5-1-8
5-1-9
© SAP AG
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. Check the transport route configuration. In transaction STMS goto Overview Transport Routes. 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://: DEPLOY_WEB_SERVICE = CTSDEPLOY 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.
E2E200
5-275
© SAP AG
E2E200
5-276
Transport Strategies
Introduction to E2E Change Control Management Solution Landscape Documentation E2E Change Diagnostics NetWeaver Development Environments Enhanced Change and Transport System Transport Strategies Change Request Management Maintenance Management Test Management IT Reporting for Change Control © SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-277
Transport Strategies: Unit Content Content: System Landscapes Client Strategies Release Management Transport Dependencies Critical Objects
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-278
Unit Objectives At the end of this unit, you will be able to: 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 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-279
Transport Strategies: Unit Overview Diagram Transport Strategies Lesson 1: System Landscapes Lesson 2: Best Practises for Running the NWDI Lesson 3: Client Strategies Lesson 4: Release Management Lesson 5: Transport Dependencies Lesson 6: Critical Objects
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-280
Transport Strategies: Unit Overview Diagram Transport Strategies Lesson 1: System Landscapes Three System Landscape Standard Transport Process Risk: Import Single Strategy Risk: Inconsistencies in the Transport Landscape Advanced Topologies
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-281
Three-system-landscape
CR
CR
CR
QAS
DEV
PRD
Buffers 2
1
3
CR
CR
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-282
Step 1: The Transport Request is Released
Systems CR
CR
CR
QAS
DEV
PRD
Buffers 1 CR
CR
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-283
Step 2: The Transport Request is Imported into QAS
Systems CR
CR
DEV
CR
QAS
PRD
Buffers 2
CR
CR
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-284
Step 3: The Transports are Imported into Production
Systems CR
CR
CR
DEV
QAS
PRD
Buffers 3
CR
CR
© SAP AG 2006, Title of Presentation / Speaker Name / 1
Step 3: The import buffer of the productive system is imported into production.
© SAP AG
E2E200
6-285
Transport Strategies: Unit Overview Diagram Transport Strategies Lesson 1: System Landscapes Three System Landscape Standard Transport Process Risk: Import Single Strategy Risk: Inconsistencies in the Transport Landscape Advanced Topologies
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-286
Risk: Import Single Strategy Problems: Transport requests are imported in an individual sequence Risk of forgotten transports Risk of version downgrades by overtakers
Solutions Import project or mass import strategy
© SAP AG 2006, Title of Presentation / Speaker Name / 1
There are several risks in a three-system-landscape: The following slides explain these risks in more detail.
© SAP AG
E2E200
6-287
Risk: Forgotten Transports
DEVK900001
DEVK900001
DEV
DEVK900002
QAS
DEVK900002
PRD
DEVK900002
1
PROG ZREPORT … CALL ZMODULE … •FUNC ZMODULE
2
3
PROG ZREPORT … CALL ZMODULE …
Test of ZREPORT in QAS is o.k.
4
PROG ZREPORT … CALL ZMODULE …
Generation of ZREPORT will lead to error
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-288
Risk: Downgrading Object Versions
DEVK900001
DEVK900001
DEV
DEVK900002
QAS
DEVK900002
PRD
DEVK900002
1
PROG ZREPORT … CALL ZMODULE …
DEVK900001
5
•FUNC ZMODULE
2
3
PROG ZREPORT … CALL ZMODULE …
Test of ZREPORT in QAS is o.k.
PROG ZREPORT … CALL ZMODULE … •FUNC ZMODULE
4
PROG ZREPORT … CALL ZMODULE …
Old version of ZREPORT is active in PRD
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-289
Consistency of Project Cycles with Import Project
Project buffer
DEV
Project buffer
QAS
PRD
Legend: Project transport requests
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-290
Transport Strategies: Unit Overview Diagram Transport Strategies Lesson 1: System Landscapes Three System Landscape Standard Transport Process Risk: Import Single Strategy Risk: Inconsistencies in the Transport Landscape Advanced Topologies
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-291
Inconsistencies in the Transport Landscape Systems
DEV
Open Developments
QAS
PRD
Transports not yet in PRD
Inconsistencies between DEV, QAS and PRD Open developments in DEV which have not yet been exported Transports in QAS which have not yet been imported to PRD
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-292
Risk: Inconsistencies in the transport landscape Reasons: Sequence violations Transports which were not transported completely Transports stay in the import buffer of QAS or PROD too long Wrong initial system set up Several parallel projects with different project timelines Projects and maintenance in parallel
Solutions: Appropriate transport strategy Pre-Production System
© SAP AG 2006, Title of Presentation / Speaker Name / 1
There are several risks in a three-system-landscape: The following slides explain these risks in more detail.
© SAP AG
E2E200
6-293
Detecting Version Inconsistencies during Bug-fixing Systems
DEV
Obj1
QAS
PRD
Object 1 is different
1) Error in production
Object 1 must be maintained
2) Object 1 is already changed in DEV and cannot be maintained
© SAP AG 2006, Title of Presentation / Speaker Name / 1
Objects which have been changed in a project that is currently in transition cannot be maintained anymore during bug-fixing.
© SAP AG
E2E200
6-294
Version Compare for Fixes between DEV and PRD Systems
DEV
Obj1V2
QAS
PRD Obj1V1
Object 1 is different
1)
Comparing active DEV object version with active PRD object version
2)
Evtl. intermediate switch DEV object version for fix
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-295
Detecting Cross Reference Errors during Bug-fixing Systems Obj1
Obj2V2
DEV
Obj1
Obj2V2
QAS Test in QAS is ok
1) Error in production
Obj1
Obj2V1
PRD
Error in PRD
Object 1 must be maintained
2) Object 1 uses Object 2. Object 2 was changed by the project 3) Test in QAS is ok 4) Error in PRD because Object 2 is still in the old version
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-296
Cross-Reference Inconsistencies and Pre-Production
Obj1V2
Obj2V2
DEV
Obj1V2
Obj2V2
QAS
Obj1V2
PRE
Obj2V1
Obj1V1
Obj2V1
PRD
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
© SAP AG 2006, Title of Presentation / Speaker Name / 1
The solution to cross-reference inconsistencies is a Pre-Production system. If the PreProduction system has the current software / configuration state of production, the error can already be detected and fixed in Pre-Production.
© SAP AG
E2E200
6-297
Transport Strategies: Unit Overview Diagram Transport Strategies Lesson 1: System Landscapes 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 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-298
Pre-Development or Sandbox System
SBX
DEV
Sandbox System
QAS
PRD
Early Prototyping without impacting the Development State Takeover from Sandbox to Development must be done manually
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-299
Pre-Production System
DEV
QAS
PRE
PRD
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 Cross Reference Errors can be detected before they go into Production
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-300
Pre-Production System in a Three System Landscape
DEV
PRE
PRD
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 Cross Reference Errors can be detected before they go into Production
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-301
Phased System Landscape (Project and Maintenance) Project Landscape
Retrofit
DEV
TST
Cut-Over Maintenance Landscape
CON
QAS
PRD
Leading Development System (no copy)
© SAP AG 2006
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-302
Typical Scenarios: • The phased system landscape is most appropriate if only one major project, with a fixed GoLive date, is developed in the project landscape. The maintenance is then performed in the maintenance landscape.
© SAP AG
E2E200
6-303
Phased System Landscape II Leading Development System (no copy)
Project Landscape
Retrofit
DEV
TST
REG
2) Sync CON and QAS
CON
QAS
1) Cut-Over
PRD
Maintenance Landscape
© SAP AG 2006
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-304
Template Roll-out Landscape Regional/Functional/Local/ 1
Central Development
– Corporate Template Test
PRD1
QAS2
PRD2
Regional/Functional/Local/ 1
CON3 – Corporate Template Development
QAS1
Regional/Functional/Local/ 1
CON2
TST
Cut-over
DEV
Cut-over
CON1
QAS3
– Test & – Cut-Over Development Verification
PRD3 – Production
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-305
• • • •
More complex system landscapes Central maintenance takes a longer way to production Recommondations …
© SAP AG
E2E200
6-306
• • • • • • •
… 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-307
Transport Strategies: Unit Overview Diagram Transport Strategies Lesson 1: System Landscapes Lesson 2: Best Practises for Running the NWDI Lesson 3: Client Strategies Lesson 4: Release Management Lesson 5: Transport Dependencies Lesson 6: Critical Objects
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-308
Track for Development of a New Release
Track: DEV DEV
CONS
TEST
PROD Approval
Runtime System DEV
Runtime System Test
Runtime System Prod
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-309
Tracks for the Maintenance of a Release
Development
Maintenance
Track: DEV DEV
CONS
Track: COR TEST
DEV
CONS
TEST
PROD
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-310
Transport Strategies: Unit Overview Diagram Transport Strategies Lesson 1: System Landscapes Lesson 2: Best Practises for Running the NWDI Lesson 3: Client Strategies Lesson 4: Release Management Lesson 5: Transport Dependencies Lesson 6: Critical Objects
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-311
Data Types in SAP Systems Customizing
#
data
Customizing
Appl. data
…. Customizing
User
Appl. User
# Customizing Customizing
#
Cross-client Customizing
SAP Repository
Development Modifications
Customer Enhancements
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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 clientindependent 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-312
Different Client Roles in 4 System Landscape
Client independent Changes
Quality Assurance
Pre-Production
Production
Client Dependant Changes DEV Test (SCC1) Authorizations Gold Client For refreshes
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-313
• 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-314
Different Client Roles in a Three System Landscape Client Independent Changes
Quality Assurance
Production
Client Dependant Changes
DEV Test (SCC1) Unit Test Authorizations Gold Client For refreshes © SAP AG 2006, Title of Presentation / Speaker Name / 1
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-315
Transport Strategies: Unit Overview Diagram Transport Strategies Lesson 1: System Landscapes Lesson 2: Best Practises for Running the NWDI Lesson 3: Client Strategies Lesson 4: Release Management Lesson 5: Transport Dependencies Lesson 6: Critical Objects
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-316
Transport Strategies: Unit Overview Diagram NetWeaver Development Environments Lesson 1: System Landscapes Lesson 2: Best Practises for Running the NWDI Lesson 3: Client Strategies Lesson 4: Release Management Parallel Projects Synchronized Releases Maintenance Cycles Change Calendar
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-317
Project Release Management
Trade Promotion Management
Go Live
Rollout CIC 1.1 Implementation CIC 2.0
01 / 2006
04 / 2006
07 / 2006
10 / 2006
01 / 2007
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-318
Object Conflicts and Object Dependencies
Project 1 Project 1 Conflicts
Dependencies
Project 2 Project 2 DEV
DEV
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-319
Cross-System Object Lock: Architecture 4.0 SAP Solution Manager Cross-System Object Lock Projects
Development System 1 Client1 … Test System
Production System
Development System 2 Client1 …
Locks are performed on LIMU level for Workbench objects and on key level for Customizing objects © SAP AG 2006, Title of Presentation / Speaker Name / 1
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-320
Pre-Production System and Project Dependencies
DEV
QAS
PRE
PRD
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 go into Production
© SAP AG 2006, Title of Presentation / Speaker Name / 1
The solution for cross-referencing inconsistencies is a Pre-Production system. If the PreProduction system has the current software / configuration state of production, the error can already be detected and fixed in Pre-Production.
© SAP AG
E2E200
6-321
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 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-322
Technical Realization: Usage of SAP IMG and CTS-Projects Create IMG project Activate CTS functionality Assign Transport Requests to CTS project
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-323
Transport Strategies: Unit Overview Diagram NetWeaver Development Environments Lesson 1: System Landscapes Lesson 2: Best Practises for Running the NWDI Lesson 3: Client Strategies Lesson 4: Release Management Parallel Projects Synchronized Releases Maintenance Cycles Change Calendar
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-324
Synchronized Release Deliveries
TPM CIC1 CIC2.v1
Synchronized 04 / 2007 Releases
CIC2.v2
07 / 2007
10 / 2007
01 / 2008
TPM: Trade Promotion Management CIC: Customer Interaction Center
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-325
Phase Control in cProjects and Change Request Management cProject Programs
Milestones
SAP Solution Manager Project
Project cycle Development phase (w/o or w/ release)
Trade Promotion Mgt.
Dev
Test phase
Emergency correction phase
Test
Go-live phase
GoLive
Customer Interaction Center
All Projects go together into the next project phase © SAP AG 2006, Title of Presentation / Speaker Name / 1
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-326
cProjects Project View
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-327
Phase Shift in Change Request Management
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-328
Advantages of Release Deliveries Advantages of Release Deliveries: Common regression testing for several projects at once Changes in production only at certain points No cross-reference dependencies with other projects Higher stability in production
Advantages of Parallel Projects: No wait times for release deliveries Individual project duration of each project is possible
Faster realization, due to individual timing of each project
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-329
Transport Strategies: Unit Overview Diagram NetWeaver Development Environments Lesson 1: System Landscapes Lesson 2: Best Practises for Running the NWDI Lesson 3: Client Strategies Lesson 4: Release Management Parallel Projects Synchronized Releases Maintenance Cycles Change Calendar
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-330
Maintenance Cycles or Single Transports
… Maintenance Cycles … Single Transports
01 / 2006
04 / 2006
07 / 2006
10 / 2006
01 / 2007
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-331
Transport Strategies: Unit Overview Diagram NetWeaver Development Environments Lesson 1: System Landscapes Lesson 2: Best Practises for Running the NWDI Lesson 3: Client Strategies Lesson 4: Release Management Parallel Projects Synchronized Releases Maintenance Cycles Change Calendar
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-332
Change Calendar – What should be contained? Which information should be contained?: Overview of current and planned projects Which projects are located in which systems Go-Live dates of projects or transports
Where is it used?: Scheduling of new projects and change requests Avoiding conflicts Aligning implementation projects and maintenance tasks
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-333
Example 1: Project Timeline
Project3 Release Development
Project2 Release Development
Project2 Integration testing Project1 Acceptance testing
Release
Project4 Release Development Project3 Integration testing
Project2 Acceptance testing
GL
Release GL
Support Package Implement.
Development
Project4 Integration testing Project3 Acceptance testing
Quality
Pre-Production Release GL
Production Critical error fix and associated update to development
1
2
3
4
GL
5
6
7
GL GLerror is discovered in When a critical production, the error-fix is done in a separate “maintenance environment” and updated 8 manually 9 to development 10 11system12 pipeline.
Maintenance
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-334
Example 2: Maintenance Planning Calendar Calender for 2006 January
ISPIWP ICP
1 Sun New Year´s Day [1] 2 Mon [1]
February
ISPIWP ICP
1 Wed
March
April
ISPIWP ICP
1 Wed I SP
ISPIWP ICP
May
June
ISPIWP ICP
1 Sat
1 Mon [18]
1 Thu
2 Sun
2 Tue
2 Fri
ISPIWP ICP
2 Thu
2 Thu
3 Tue
3 Fri
3 Fri
3 Wed
3 Sat
4 Wed
4 Sat
4 Sat
4 Tue
4 Thu
4 Sun W hitsunday (G)
5 Thu
5 Sun
5 Sun
5 Wed
5 Fri
5 Mon Whitemanday (G) [23]
6 Fri Epiphany (G)
6 Mon [6]
ICP IWP
6 Mon [10]
3 Mon [14]
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 Sun Easter Day
16 Tue
17 Mon Easter Monnday (G) [16]
17 Wed
16 Mon [3]
16 Thu
16 Thu
17 Tue
17 Fri
17 Fri
I SP ICP IWP
16 Fri 17 Sat I SP
18 Sun
18 Wed
18 Sat
18 Sat
18 Tue
18 Thu
ICP
19 Thu
19 Sun
19 Sun
19 Wed
19 Fri
IWP
20 Fri
20 Mon [8]
20 Mon [12]
20 Thu
20 Sat DC Main (G)
20 Tue
19 Mon [25]
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
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)
24 Sat
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 end ISP ReleaseDelivery Time
QuarterEndClosing
PCB M aint enance Delivery
ISW ReleaseDelivery Time
YearEndClosing
PCB Release Delivery
ICP ReleaseDelivery Time
EM (f or Emergency Request)
Import
M aintenanceDelivery
ReleaseDelivery
DB Reo rg
I *P
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-335
Project Overview in SAP Solution Manager
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-336
Project Overview in Change Request Management
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-337
Transport Strategies: Unit Overview Diagram Transport Strategies Lesson 1: System Landscapes Lesson 2: Best Practises for Running the NWDI Lesson 3: Client Strategies Lesson 4: Release Management Lesson 5: Transport Dependencies Lesson 6: Critical Objects
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-338
Transport Strategies: Unit Overview Diagram Transport Strategies Lesson 1: System Landscapes Lesson 2: Best Practises for Running the NWDI Lesson 3: Client Strategies Lesson 4: Release Management Lesson 5: Transport Dependencies Customizing Synchronization Synchronization of Transports Special Dependencies
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-339
Consistent Customizing between Systems
ERP-DEV
ERP-QAS
ERP-PRD
CRM-DEV
CRM-QAS
CRM-PRD
replicate
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.
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-340
Customizing Distribution: Overview
Customizing data
Synchronization Group
SAP Solution Manager with Customizing Distribution
source settings
target settings
R/3 DEV
Transport
R/3 QAS
Transport
R/3 PRD
CRM DEV
Transport
CRM QAS
Transport
CRM PRD
... DEV
Transport
... QAS
Transport
... PRD
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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 standalone HR.
© SAP AG
E2E200
6-341
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
SAP ERP DEV
2 Notify Solution Manager
about customizing changes
SAP Solution Manager
SAP ERP QAS Time zones Transport zones Currencies Customer groups Product groups ...
3 Map source to target customizing, after importing changes
SAP ERP PRD
Save customizing into
1 transport request
Send target settings
4 to target system
Log
SAP CRM DEV
SAP CRM QAS
SAP CRM PRD
6 Generate distribution logs Time zones Transport zones Currencies Customer groups ...
5
Write target settings into transport request
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-342
How To Set Up Customizing Distribution Define customizing distribution scenario: What? – Synchronization group From where to where? – Source and target systems At 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)
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-343
Transport Strategies: Unit Overview Diagram Transport Strategies Lesson 1: System Landscapes Lesson 2: Best Practises for Running the NWDI Lesson 3: Client Strategies Lesson 4: Release Management Lesson 5: Transport Dependencies Customizing Synchronization Synchronization of Transports Special Dependencies
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-344
Change Request Management in a mySAP Business Suite Solution Development Landscape Development Environment
System
QA Landscape
Production Landscape
System
System
Transport Landscape ERP
SE80 DS & DI
mySAP ERP
mySAP ERP
mySAP ERP
Transport Landscape CRM
SE80 DS & DI
mySAP CRM
mySAP CRM
mySAP CRM
Transport Landscape EP
Portal Content Administrator DS & DI
Enterprise Portal
Enterprise Portal
Enterprise Portal
Transport Landscape BI
BI
BI
BI
DS & DI
Transport Landscape PI
SE80 Integration Builder
Process Integration (XI)
Process Integration (XI)
Process Integration (XI)
SE80
Change Request Management
SAP Solution Manager © SAP AG 2006, Title of Presentation / Speaker Name / 1
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-345
Solution Manager Project Comprises Several Transport Tracks
Solution Manager Project – Development Environment - ERP Transport Request1 Transport Request2
- CRM Transport Request3
- BW Transport Request4
– Quality Assurance Environment - ERP - CRM - BW
– Production Environment - ERP - CRM - BW
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-346
Transport Strategies: Unit Overview Diagram Transport Strategies Lesson 1: System Landscapes Lesson 2: Best Practises for Running the NWDI Lesson 3: Client Strategies Lesson 4: Release Management Lesson 5: Transport Dependencies Customizing Synchronization Synchronization of Transports Special Dependencies
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-347
Data Consistency between Systems: CRM Delta Load
Master Data
Master Data
ERP-DEV
ERP-QAS
Config
ERP-PRD
Config
1 Master Data
CRM-DEV Config
Master Data
2
CRM-QAS
CRM-PRD
Config
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. © SAP AG 2006, Title of Presentation / Speaker Name / 1
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-348
Data Consistency between Systems: OLTP and OLAP A
ERP-DEV
1
Data Source
2
Replicated DS
BI-DEV
ERP-PRD
Data Source
B
Transfer Rules
ERP-QAS
Replicated
3
BI-QAS
BI-PRD
Transfer Rules
C
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 © SAP AG 2006, Title of Presentation / Speaker Name / 1
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-349
Transport Strategies: Unit Overview Diagram Transport Strategies Lesson 1: System Landscapes Lesson 2: Best Practises for Running the NWDI Lesson 3: Client Strategies Lesson 4: Release Management Lesson 5: Transport Dependencies Lesson 6: Critical Objects
© SAP AG 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-350
Critical Transport Objects Uncritical Objects: Forms, e.g. SAP Scripts Authorizations Simple Customizing (without generation of repository objects)
Critical Objects: Customizing with generation of repository objects (e.g. LIS) Report sources Dictionary 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)
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-351
Critical Business Objects Critical Business Objects are: SD condition tables User exits Complete development classes in business critical areas
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-352
Checking for Critical Objects
DEV: 0 QAS: 7 PRD: 3
Request 1 DEVK900016 2 DEVK900018 3 DEVK900020 4 DEVK900023 5 DEVK900002 6 DEVK900033 7 DEVK900035
Object list Object list ZABAP R3TR PROG Object list ZABAP R3TR PROG R3TR TABU Object listZTABLE R3TR PROG ZABAP R3TR TABU ............... Object listZTABLE R3TRTABU PROG ZABAP R3TR ZTABLE ............... Object list R3TRTABU PROG ZABAP R3TR ZTABLE ............... Object list R3TRTABU PROG ZABAP R3TR ZTABLE ............... Object list R3TRTABU PROG ZABAP R3TR ZTABLE ............... R3TRTABU PROG ZABAP R3TR ZTABLE ............... R3TR TABU ZTABLE ............... ...............
Compare critical objects
R3TR
TABU
ZTABLE
Table of critical objects © SAP AG 2006, Title of Presentation / Speaker Name / 1
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-353
Approval of Critical Objects in Change Request Management
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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 GoLive. Critical objects can be configured in transaction is /TMWFLOW/CMSCONF.
© SAP AG
E2E200
6-354
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_.PFL No generation of programs and screens Start SGEN for transport request (uses several processes) or start the report
RSGENINVLAS
Business Warehouse : Long Import Times due to long running After-Import-Methods Do not allow Data Load during Imports, Queries might be okay Import Single should be used
© SAP AG 2006, Title of Presentation / Speaker Name / 1
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-355
Unit Summary You should now be able to: 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 2006, Title of Presentation / Speaker Name / 1
© SAP AG
E2E200
6-356
© SAP AG
E2E200
6-357
Exercises Unit:
Transport Strategies
In this exercise, you can test your knowledge on system landscapes and transport strategies
This exercise consists of questions and answers.
6-1
What are risks when using the Import Single strategy? More than one answer is correct. Decide whether each answer is true or false.
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? Please choose the correct answer. Global rollout landscape Separate development client for each project
© SAP AG
E2E200
6-358
Preproduction system 6-3
What are advantages of a phased system landscape? More than one answer is correct. Decide whether each answer is true or false.
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-359
Solutions Unit:
6-1
Transport Strategies
What are risks when using the Import Single strategy? More than one answer is correct. Decide whether each answer is true or false.
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? Please choose the correct answer.
O
Global rollout landscape
O
Separate development client for each project
X
Preproduction system
© SAP AG
E2E200
6-360
6-3
What are advantages of a phased system landscape? More than one answer is correct. Decide whether each answer is true or false.
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
6-361
Change Request Management
Introduction to E2E Change Control Management Solution Landscape Documentation E2E Change Diagnostics NetWeaver Development Environments Enhanced Change and Transport System Transport Strategies Change Request Management Maintenance Management Test Management IT Reporting for Change Control © SAP AG 2007
© SAP AG
E2E200
7-362
Change Request Management: Unit Content Content: Change Request Management Overview Project and Release Management Change Requests Maintenance Activities Implementation Projects Tools Best Practices
© SAP AG 2007
© SAP AG
E2E200
7-363
Unit Objectives At the end of this unit, you will be able to: 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 2007
© SAP AG
E2E200
7-364
Change Request Management Unit Overview Diagram Change Request Management 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 2007
© SAP AG
E2E200
7-365
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 projects Periodic maintenance Emergency corrections
Change Request Management strengthens the strategy of SAP Solution Manager, as SAP‘s application management platform which: Ensures reliability Reduces Total Cost of Ownership and increases Total Solution Value Bridges the gap between business requirements and IT
administration
© SAP AG 2007
© SAP AG
E2E200
7-366
ITIL Change Management Process Create RfC Rejected: New RfC
Classify: Category and Priority
yes
Urgent? no
Urgent Correction
Configuration Management processes the data and controls the status of the CIs
Accept: Filter RfC
Plan: Impact und Resources Correct
Coordinate Develop Test
no
Control
Fallback
Implement
yes
Evaluate and close
© SAP AG 2007
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-367
Three tiers of Change Request Management SAP Solution Manager Change Admin
Project Management
Management of all change requests
Project Administration
Change request categorization
Project documentation
Change documentation
Project Blueprint & Configuration
Approval workflow
Test Management
Status reporting
Learning Management
cProject Administration
Change Logistics Development & Customizing Infrastructure Workbench Organizer Transport Management Transport scheduling Transport tracking
© SAP AG 2007
© SAP AG
E2E200
7-368
Change Request Management – Roles in a Nutshell
Requestor
… creates an Service Message or a Change Request directly.
Service Desk … handles the Service Message and creates a Change Request. Employee Change Manager
… categorizes, approves and monitors Change Requests.
Change Advisory Board
… is the Steering Committee in the Change Management process.
Developer
… implements a change and hands over to the Tester.
Tester
… tests a change, sets status in the Change Document.
IT Operator
… takes care of software logistics.
© SAP AG 2007
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-369
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-370
Change Request Management Unit Overview Diagram Change Request Management 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 2007
© SAP AG
E2E200
7-371
Release Management & Change Request Management SAP Solution Manager
Project cycle transaction
Project cycle task list
Physical (development) systems
Logical systems (clients) Transport Request CTS project
IMG project
CTS project
...
cProjects
Project created in cProjects
CTS project
SAP Solution Manager project
IMG project
CTS project CTS project CTS project
...
...
© SAP AG 2007
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-372
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.
© SAP AG 2007
This is the IT Infrastructure Library (ITIL) definition of release management. ITIL is the defacto global standard for service management. For more information, go to www.itil.org
© SAP AG
E2E200
7-373
SAP Solution Manager Projects and Project Cycles
cProject SAP Solution Manager project
Project cycle Development phase (w/o or w/ release)
Test phase
Emergency correction phase
Go-live phase
© SAP AG 2007
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-374
Change Request Management – Cycle Management
Change Request Management
SAP Solution Manager
Cycle Transaction
Change Manager
PRD
Controlled transports
Project Cycle QAS
Cycle Task List
Controlled transports
DEV
© SAP AG 2007
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-375
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 production
systems) 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 one
development system A CTS Project represents an IMG project in one client
© SAP AG 2007
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-376
Project Cycle II Project cycles generate the phase instance of a project Only one active cycle can exist simultaneously for each project Project Cycles: control project phases control whether or not transports are created, exported, or imported incorporate all logical systems that belong to a project can be closed after the go-live phase, or reset to the “In Development”
phase The project types that are supported are: Template project Implementation project Upgrade project Maintenance project (special semantics apply and will be explained
later)
© SAP AG 2007
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-377
Change Request Management Unit Overview Diagram Change Request Management 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 2007
© SAP AG
E2E200
7-378
Change Request Management – Change Request
Change Request Management
Service Desk
SAP Solution Manager Service Desk Employee
Service Message SLFN
Change Request SDCR
Feedback
Requester
Change Manager
Change Transaction SDMJ / SDHF
© SAP AG 2007
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-379
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 change is required for. The entry in the Subject field is used to identify the project type and the change process type. Project types: Template Implementation Upgrade Maintenance 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, Products Extended general Customizing (project): Event-driven notifications,
feedback, cost management, extended custom fields and custom tabs Extended change request-specific Customizing (project): Text profiles, activity profiles, status schema, transaction types © SAP AG 2007
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-380
Approval Process: Create and Accept RfC
Create RfC Rejected: New RfC
Accept: Filter RfC
That is not what I have required!
Urgent?
yes
Urgent Correction
Classify: Category and Priority
no
Plan: Impact und Ressources
It is not my fault someone else was responsible for it!
© SAP AG 2007
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-381
Approval Process: Classify and Plan RfC
Create RfC Rejected: New RfC
Accept: Filter RfC
I had other prioritiesthat's why I‘m too late!
Urgent?
yes
Urgent Correction
Classify: Category and Priority
no
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
Plan: Impact und Ressources
© SAP AG 2007
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-382
Plan: Impact and Resources • Complexity of change • Business areas affected • Critical objects check • Regression test required
© SAP AG
E2E200
7-383
System-Demo
System-Demo
© SAP AG 2007
© SAP AG
E2E200
7-384
Exercise
Exercise
© SAP AG 2007
© SAP AG
E2E200
7-385
Change Request Management Unit Overview Diagram Change Request Management 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 2007
© SAP AG
E2E200
7-386
Change Request Management Unit Overview Diagram Change Request Management Lesson 4: Maintenance Activities Maintenance Project Maintenance Cycle Urgent Correction Normal Correction Test Message Administration Activities
© SAP AG 2007
© SAP AG
E2E200
7-387
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 2007
© SAP AG
E2E200
7-388
Harmonizing Maintenance Activities cProject SAP Solution Manager Project (Maintenance Project)
Maintenance Cycle Development (w/o or w/ release)
Emergency Correction
Test
Harmonization
Harmonization
Go-Live
Harmonization
Normal Corrections
Test messages (during integration test)
Urgent Corrections (independent of MC)
© SAP AG 2007
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-389
Change Request Management Unit Overview Diagram Change Request Management Lesson 4: Maintenance Activities Maintenance Project Maintenance Cycle Urgent Correction Normal Correction Test Message Administration Activities
© SAP AG 2007
© SAP AG
E2E200
7-390
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 a new 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 2007
© SAP AG
E2E200
7-391
Change Request Management Unit Overview Diagram Change Request Management Lesson 4: Maintenance Activities Maintenance Project Maintenance Cycle Urgent Correction Normal Correction Test Message Administration Activities
© SAP AG 2007
© SAP AG
E2E200
7-392
Harmonizing Maintenance Activities cProject SAP Solution Manager Project (Maintenance Project)
Maintenance Cycle Development w/o or w/ release
Emergency Correction
Test
Go-Live
Normal Corrections
Test messages (during integration test)
Urgent Corrections (independent of MC)
© SAP AG 2007
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-393
Change Request Management – Urgent Correction
Change Request Management
Service Desk
SAP Solution Manager Service Desk Employee
Service Message
Change Request Developer
Feedback
Requester
Change Manager
PRD
Controlled transports
Tester
Change Document
Task List
QAS
Controlled transports
Maintenance Cycle
IT Operator
DEV
© SAP AG 2007
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-394
System-Demo
System-Demo
© SAP AG 2007
© SAP AG
E2E200
7-395
Change Request Management Unit Overview Diagram Change Request Management Lesson 4: Maintenance Activities Maintenance Project Maintenance Cycle Urgent Correction Normal Correction Test Message Administration Activities
© SAP AG 2007
© SAP AG
E2E200
7-396
Harmonizing Maintenance Activities cProject SAP Solution Manager Project (Maintenance Project)
Maintenance Cycle Development w/o or w/ release
Harmonization
Emergency Correction
Test
Harmonization
Go-Live
Harmonization
Normal Corrections
Test messages (during integration test)
Urgent Corrections (independent of MC)
© SAP AG 2007
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-397
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 request Project exports and imports can be managed by the maintenance task-list
© SAP AG 2007
© SAP AG
E2E200
7-398
Change Request Management – Normal Correction
Change Request Management
Service Desk
SAP Solution Manager Service Desk Employee
Feedback
Service Message
Requester
Change Request Developer
Tester
PRD Change Manager
Change Document
Controlled transports
Maintenance Cycle QAS
Controlled transports
IT Operator DEV
© SAP AG 2007
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 tasklist. 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-399
Consistent Normal Corrections in a Project Cycle
Import buffer
DEV
Import buffer
QAS
PRD
Legend: Normal Corrections Test Transports (Transport of Copies)
© SAP AG 2007
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-400
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-401
Consistency of Urgent Corrections and Maintenance Activities
Transport buffer
DEV
Transport buffer
QAS
PRD
Legend: Maintenance Activities Urgent Correction Consolidated Transport
© SAP AG 2007
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-402
Differences Between Urgent and Normal Corrections
Normal Correction
Urgent Correction
No individual task list. The task list of the maintenance cycle is used.
An individual task list is used.
Transports have to be created manually, using the actions of the change transaction.
Transports are generated automatically.
Transports are exported and imported in accordance with the phases of the maintenance cycle.
Transports can be propagated directly into the follow-on systems, but remain in the transport buffer.
A violation of the separation of functions is only a warning.
Developer and tester must be different persons.
© SAP AG 2007
© SAP AG
E2E200
7-403
System-Demo
System-Demo
© SAP AG 2007
© SAP AG
E2E200
7-404
Exercise
Exercise
© SAP AG 2007
© SAP AG
E2E200
7-405
Change Request Management Unit Overview Diagram Change Request Management Lesson 4: Maintenance Activities Maintenance Project Maintenance Cycle Urgent Correction Normal Correction Test Message Administration Activities
© SAP AG 2007
© SAP AG
E2E200
7-406
Harmonizing Maintenance Activities cProject SAP Solution Manager Project (Maintenance Project)
Maintenance Cycle Development w/o or w/ release
Harmonization
Emergency Correction
Test
Harmonization
Go-Live
Harmonization
Normal Corrections
Test messages (during integration test)
Urgent Corrections (independent of MC)
© SAP AG 2007
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-407
Change Request Management – Test Message
Change Request Management
SAP Solution Manager
Cycle Transaction Developer
Change Manager
PRD
Controlled transports
Tester
Test Message
Cycle Task-list
QAS
Controlled transports
Project Phases DEV
© SAP AG 2007
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-408
Change Request Management Unit Overview Diagram Change Request Management Lesson 4: Maintenance Activities Maintenance Project Maintenance Cycle Urgent Correction Normal Correction Test Message Administration Activities
© SAP AG 2007
© SAP AG
E2E200
7-409
Harmonizing Maintenance Activities cProject SAP Solution Manager Project (Maintenance Project)
Maintenance Cycle Development (w/o or w/ release)
Synchronizing
Emergency Correction
Test
Synchronizing
Go-Live
Synchronizing
Admin.
© SAP AG 2007
Administration messages can be created during all operational phases of a project and allow logon to any project landscape system.
© SAP AG
E2E200
7-410
Change Request Management – Administration Message
Change Request Management
Service Desk
SAP Solution Manager Service Desk Employee
Service Message
Change Request
Admin Message
Feedback
Requester
Change Manager
Cycle Task-list
PRD
QAS
Project Phases
IT Operator
DEV
© SAP AG 2007
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-411
Change Request Management Unit Overview Diagram Change Request Management 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 2007
© SAP AG
E2E200
7-412
Harmonizing Project Activities
cProject SAP Solution Manager Project (Imp./Upgrade/Temp.Project)
Project Cycle Development (w/o or w/ release)
Preparation for Go-Live
Test
Harmonization
Harmonization
Go-Live
Harmonization
Normal Corrections Admin Test messages (during integration test)
© SAP AG 2007
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-413
Change Request Management Unit Overview Diagram Change Request Management 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 2007
© SAP AG
E2E200
7-414
Change Request Management Unit Overview Diagram Change Request Management Lesson 6: Tools Change Request Management Reporting SAP Change Manager Cross System Object Lock Critical Object Approval Process Retrofit
© SAP AG 2007
© SAP AG
E2E200
7-415
Change Management Reporting - Requirements
Development
Quality
Productive
Poll via RFC
Poll via RFC
SAP Solution Manager
Poll via RFC
Change Request Management configured Data Collector job is scheduled
© SAP AG 2007
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-416
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 2007
© SAP AG
E2E200
7-417
Change Request Management Reporting: Access Transaction /TMWFLOW/REPORTING (cross-solution reporting)
© SAP AG 2007
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-418
Change Request Management Reporting: Status of Data
© SAP AG 2007
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-419
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 screen and 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 List group 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 2007
© SAP AG
E2E200
7-420
Exercise
Exercise
© SAP AG 2007
© SAP AG
E2E200
7-421
Appendix
Possibilities Examples
© SAP AG 2007
© SAP AG
E2E200
7-422
Selecting List of Events Results lists can be configured according to the entries in the following fields: Grid fields: Header, Header, Project, and Task List Header, Project, Task List, and Transport Requests Header, Project, Task List, Transport Request, and Transport Objects SAP Notes and Support Packages Support 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 2007
© SAP AG
E2E200
7-423
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 number Create and change dates User status and system status
OrgUnits: Business partner number and function Reference 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 2007
© SAP AG
E2E200
7-424
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 Component Transport Track IMG and CTS Project
Task list data: All task lists and cycle task list Task 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 2007
© SAP AG
E2E200
7-425
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 2007
© SAP AG
E2E200
7-426
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 Name Package Name View Name Table 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 2007
© SAP AG
E2E200
7-427
Change Request Management Reporting: Selection Example Display all change transactions (urgent corrections, for example) that are being processed in the current system
In Syst. Status group box select In Process
Transaction Type field -> F4 to select relevant types (SDHF, for example)
© SAP AG 2007
© SAP AG
E2E200
7-428
Change Request Management Reporting: Results Example Results of previous query Header data about the selected transaction type is displayed
To navigate to change transaction (here: urgent correction) double-click relevant entry in column Transaction ID
© SAP AG 2007
© SAP AG
E2E200
7-429
Change Request Management Reporting: Selection Example Display all transport requests belonging to a change request (or urgent correction, maintenance, and so on) Important: Always choose Reset Selection Fields before starting a new query
In Result List group box, select Header, Project, Task List, and Transports In Document Number field, enter the number © SAP AG 2007
© SAP AG
E2E200
7-430
Change Request Management Reporting: Results Example Results of previous query: Header, project, task list, and transport data about the selected transaction are displayed
Columns highlighted in color: You can navigate to relevant transaction, project, and so on by doubleclicking relevant entry
© SAP AG 2007
© SAP AG
E2E200
7-431
Change Request Management Reporting: Selection Example Display which transactions a transport request belongs to.
© SAP AG 2007
© SAP AG
E2E200
7-432
Change Request Management Reporting: Results Example Results of previous query: Transactions that belong to the selected transport request are displayed.
© SAP AG 2007
© SAP AG
E2E200
7-433
Change Request Management Reporting: Selection Example Display change requests that were created by a particular change manager.
Select transaction type.
Use F4 to select partner number of a change manager.
© SAP AG 2007
© SAP AG
E2E200
7-434
Change Request Management Reporting: Results Example Results of previous query: Change requests created by the selected change manager are displayed.
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
© SAP AG 2007
© SAP AG
E2E200
7-435
Change Request Management Reporting: Selection Example Display all transactions for a particular production system (IBase component).
Use F4 to select Installed Base Component
© SAP AG 2007
© SAP AG
E2E200
7-436
Change Request Management Reporting: Results Example Results of previous query: Transactions are displayed for the selected IBase component.
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
© SAP AG 2007
© SAP AG
E2E200
7-437
Change Request Management Reporting: Selection Example Display which transactions have transported a particular Customizing object. Additional selection criteria can be entered (view name, and so on)
Use F4 to select Customizing Objects
© SAP AG 2007
© SAP AG
E2E200
7-438
Change Request Management Reporting: Results Example Results of previous query: Transactions that have transported the Customizing object T005X are displayed.
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
© SAP AG 2007
© SAP AG
E2E200
7-439
Change Request Management Reporting: Selection Example Display all transactions whose maintenance project status is completed.
© SAP AG 2007
© SAP AG
E2E200
7-440
Change Request Management Reporting: Results Example Results of previous query: Transactions whose maintenance project status is completed are displayed.
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
© SAP AG 2007
© SAP AG
E2E200
7-441
Change Request Management Reporting: Selection Example for a Specific Solution Display all change requests created for a particular solution (including project data).
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.
© SAP AG 2007
© SAP AG
E2E200
7-442
Change Request Management Unit Overview Diagram Change Request Management Lesson 6: Tools Change Request Management Reporting SAP Change Manager Cross System Object Lock Critical Object Approval Process Retrofit
© SAP AG 2007
© SAP AG
E2E200
7-443
Change Manager: Change Tracking I
© SAP AG 2007
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-444
Change Manager: Change Tracking II
© SAP AG 2007
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-445
Change Manager: Scheduling Tool
© SAP AG 2007
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
E2E200
7-446
Change Manager: Task-List
© SAP AG 2007
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
E2E200
7-447
Change Manager: Task List II
© SAP AG 2007
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
E2E200
7-448
Change Manager: Task List III
© SAP AG 2007
Monitor tasks with detail log information
© SAP AG
E2E200
7-449
Change Request Management Unit Overview Diagram Change Request Management Lesson 6: Tools Change Request Management Reporting SAP Change Manager Cross System Object Lock Critical Object Approval Process Retrofit
© SAP AG 2007
© SAP AG
E2E200
7-450
Downgrade Risk with Urgent Corrections
Project Buffer
3 1 4
DEV
Project Buffer
3 1
QAS
PRD
2
Legend:
Urgent Corrections
© SAP AG 2007
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
E2E200
7-451
Downgrade Risk with Normal Corrections
Project Buffer
DEV
Project Buffer
QAS
PRD
Legend:
Project1 Project2 Project3 © SAP AG 2007
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
E2E200
7-452
Cross-System Object Lock: Architecture 4.0 SAP Solution Manager Cross-System Object Lock Projects
Development System 1 Client1 … Test System
Production System
Development System 2 Client1 …
© SAP AG 2007
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-453
Cross-System Lock SAP Solution Manager Cross-System Object Lock Projects NC(O1) – P1 NC(O1) - P2 UC(O2) – P1 UC(O2) – P1 NC(O3) – P2
Test System
NC(O1) – P2 – SYS1 failed UC(O2) – P1 – SYS1 failed NC(O3) – P2 – SYS1 failed UC(O2) – P2 – SYS2 failed
Production System
NC(O3) – P2 UC(O2) – P2
© SAP AG 2007
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-454
- Other changes are recognized – Warning
© SAP AG
E2E200
7-455
Change Request Management Unit Overview Diagram Change Request Management Lesson 6: Tools Change Request Management Reporting SAP Change Manager Cross System Object Lock Critical Object Approval Process Retrofit
© SAP AG 2007
© SAP AG
E2E200
7-456
Critical Object Approval Process Critical objects are approved at the time of export. Critical objects are defined as: Modifications Workbench objects in transport piece list format Customizing objects in transport piece list format
Critical object check is activated for each logical system: R3TR objects LIMU objects Logical objects for Customizing views Table entries for Customizing tables
Modification approval is activated once in SAP Solution Manager: Activate for each logical system
© SAP AG 2007
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 GoLive.
© SAP AG
E2E200
7-457
Critical Object Definition
© SAP AG 2007
For the definition of critical objects use the transaction /TMWFLOW/CMSCONF critical object tab page The check can be activated on a system-level and a client-specific level.
© SAP AG
E2E200
select the
7-458
Critical Object Approval
© SAP AG 2007
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 contains critical objects!
© SAP AG
E2E200
7-459
Change Request Management Unit Overview Diagram Change Request Management Lesson 6: Tools Change Request Management Reporting SAP Change Manager Cross System Object Lock Critical Object Approval Process Retrofit
© SAP AG 2007
© SAP AG
E2E200
7-460
Review: Phased System Landscape Project Landscape
TST
Retrofit
DEV
Maintenance Landscape
CON
QAS
PRD
© SAP AG 2007
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-461
Outlook: Retrofit Process
© SAP AG 2007
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-462
Change Request Management Unit Overview Diagram Change Request Management 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 2007
© SAP AG
E2E200
7-463
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 change Normal Corrections for midterm and long-term changes Maintenance projects for housekeeping activities Implementation projects for new implementations
© SAP AG 2007
© SAP AG
E2E200
7-464
Change Request Management Unit Overview Diagram Change Request Management Lesson 7: Best Practices Review Best Practice for Transport Management Use Case: System Landscape Approach Use Case: Implementation Complexity
© SAP AG 2007
© SAP AG
E2E200
7-465
Best Practices: Usage of Projects Implementation Projects
Development
Test
Production
Implementation Project Market Campaign Complaint Management Rollout Brazil
Maintenance Project ERP … … Maintenance Cycles … Urgent Corrections
© SAP AG 2007
Advantages: • Comprehensive customizing and development activities are grouped together • Basis for Release Management
© SAP AG
E2E200
7-466
Best Practices: Phase Switching cProject SAP Solution Manager Project (Maintenance Project)
Project Phases Development (w/o or w/ release)
Emergency Correction
Test
Synchronizing
Synchronizing
Go-Live
…
Synchronizing
Normal Corrections
No export
No export
No export
Urgent Corrections (independent of MC)
© SAP AG 2007
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-467
Best Practices: Urgent Corrections are Preliminary Transports
Transport buffer
DEV
Transport buffer
QAS
PRD
Legend: Maintenance Activities Urgent Correction Consolidated Transport
© SAP AG 2007
Advantage: • Consolidated Transports guarantee consistent project import/deployment.
© SAP AG
E2E200
7-468
Best Practices: Usage of Test Transports
Project buffer
DEV
Project buffer
QAS
PRD
Legend: Normal Corrections Test Transports (Transport of Copies)
© SAP AG 2007
Advantage: • The Project buffer of the PRD System only contains consolidated changes.
© SAP AG
E2E200
7-469
Best Practice: Cross-System Object Lock SAP Solution Manager Cross-System Object Lock Projects
Development System 1 Client1 … Test System
Production System
Development System 2 Client1 …
© SAP AG 2007
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-470
Best Practices: Critical Object Approval
© SAP AG 2007
Advantage: • Identify changes on critical objects (Prerequisite: knowledge of this objects)
© SAP AG
E2E200
7-471
Best Practices: Retrofit Project Landscape
TST
Retrofit
DEV
Maintenance Landscape
CON
QAS
PRD
© SAP AG 2007
Advantages: • Tool based • Minimized Risk through integration in the maintenance project • Logging of the changes
© SAP AG
E2E200
7-472
Change Request Management Unit Overview Diagram Change Request Management Lesson 7: Best Practices Review Best Practice for Transport Management Use Case: System Landscape Approach Use Case: Implementation Complexity
© SAP AG 2007
© SAP AG
E2E200
7-473
Change Request Management with Pre-Production System (example)
DEV
QAS
PRE
PRD
© SAP AG 2007
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-474
Change Request Management with Phased System Landscape (example) Project Landscape
TST
Retrofit
DEV
Maintenance Landscape
CON
QAS
PRD
© SAP AG 2007
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-475
Phased System Landscape: Phase Development Project Landscape
TST
Retrofit
DEV
Maintenance Landscape
CON
QAS
PRD
© SAP AG 2007
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-476
Phased System Landscape: Phase Test Project Landscape
QAS
TST
Retrofit
DEV
Maintenance Landscape
CON
PRD
© SAP AG 2007
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-477
Phased System Landscape: Phase Go-Live Project Landscape
QAS
TST
Retrofit
DEV
Cut-Over Maintenance Landscape
CON
PRD
© SAP AG 2007
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-478
Phased System Landscape: Next Cycle Project Landscape
TST
Retrofit
DEV
Maintenance Landscape
CON
QAS
PRD
© SAP AG 2007
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-479
Change Request Management Unit Overview Diagram Change Request Management Lesson 7: Best Practices Review Best Practice for Transport Management Use Case: System Landscape Approach Use Case: Implementation Complexity
© SAP AG 2007
© SAP AG
E2E200
7-480
Transport Management Approach
Change Request Management
SAP Solution Manager
Cycle Transaction
PRD
Controlled transports
Project Cycle QAS
Cycle Task-List
Controlled transports
DEV IT Operator
© SAP AG 2007
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-481
Extension: Change Document
Change Request Management
SAP Solution Manager
PRD Developer Controlled transports
Tester
Change Document
TaskList
QAS
Controlled transports
Project Cycle
IT Operator
DEV
© SAP AG 2007
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-482
Extension: Approval Process SAP Solution Manager
Change Request Management
Requester
Change Request Developer
Change Manager
PRD
Controlled transports
Tester
Change Document
TaskList
QAS
Controlled transports
Project Cycle
IT Operator
DEV
© SAP AG 2007
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-483
Extension: Service Desk
Change Request Management
Service Desk
SAP Solution Manager Service Desk Employee
Service Message
Change Request Developer
Feedback
Requester
Change Manager
PRD
Controlled transports
Tester
Change Document
TaskList
QAS
Controlled transports
Project Cycle
IT Operator
DEV
© SAP AG 2007
This Extension bridges the gap between the incident / problem management process and the change / release management process.
© SAP AG
E2E200
7-484
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 2007
© SAP AG
E2E200
7-485
© SAP AG
E2E200
7-486
Exercises Unit: Lesson:
Change Request Management 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-487
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-488
Exercises Unit: Lesson:
Change Request Management 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 7-3-6
7-3-7
© SAP AG
____________________________________________________________ _ Click on button Actions and choose Set to ‘In Development’. Save the document 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. Click on button Actions and choose Logon to System to log on to the development system via a trusted RFC connection. E2E200
7-489
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-490
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-491
Exercises Unit: Lesson:
Change Request Management 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-492
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-493
Solutions Unit: Lesson:
7-1
Change Request Management Change Requests
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-494
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 7-2-5
Go into change mode: Classify the change request as a normal correction. Open the F4 help at the field Subject. There you can choose Normal Correction (Maintenance). Save. Approve the change request. Choose button Actions and then Authorize Change Request.
7-2-6
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-495
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-496
7-2-7
Write down the change document number. Choose document flow to access the number. ____________________________________________________________ _ • •
© SAP AG
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.
E2E200
7-497
© SAP AG
E2E200
7-498
Solutions Unit: Lesson: 7-3
Change Request Management Maintenance Activities
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”. 7-3-9
© SAP AG
Choose Search for the entry of your user and change the description.
E2E200
7-499
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-500
Solutions Unit: Lesson:
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 7-4-4 7-4-5 7-4-6
7-5
Change Request Management Tools
Open the transaction data screen area by clicking the button. In the field Document Number fill in the number of your change document you wrote down in Exercise “Change Requests” Execute your selection Press button or choose F8. Check your results and find the transport request. Please write down the transport request:
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-501
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 7-5-4
Open the transport request screen area by clicking the button. In the field Request/Task fill in the number of the transport request you just wrote down in 1-1-6. Execute your selection. Press button or choose F8. Check your results and find the object. Please write down the object:
7-5-5 7-5-6
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 7-6-4
Open the transport objects screen area by clicking the button. 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. Check your results.
7-6-6
© SAP AG
E2E200
7-502
Maintenance Management
Introduction to E2E Change Control Management Solution Landscape Documentation E2E Change Diagnostics Netweaver Development Environments Enhanced Change and Transport System Transport Strategies Change Request Management Maintenance Management Test Management IT Reporting for Change Control © SAP AG 2007
© SAP AG
E2E200
8-503
Maintenance Management 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 2007
© SAP AG
E2E200
8-504
Maintenance Management: Unit Objectives At the end of this unit, you will be able to: 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 2007
© SAP AG
E2E200
8-505
Maintenance Management Unit Overview Diagram Maintenance Management Lesson 1: SAP Maintenance Strategy Lesson 2: Types of Corrections Lesson 3: Support Package Stack Strategy Lesson 4: Side-Effect Reporting Lesson 5: Support Package Content Analysis Lesson 6: Applying Support Packages Lesson 7: Maintenance Optimizer Lesson 8: HotNews Inbox
© SAP AG 2007
© SAP AG
E2E200
8-506
Release and Maintenance Strategy mySAP ERP Enh. Packages 2005.3 2005.2 2005.1
mySAP ERP 2005
RampUp
mySAP ERP 2004
Ext. Maint. (+ 2%)*
Mainstream Maintenance
Ext. Maint. (+ 2%)*
Mainstream Maintenance
Ext. Maintenance (+ 4%)*
Ext. Maintenance (+ 4%)*
Customer-Specific Maintenance
SAP R/3 Enterprise 47x200
Mainstream Maintenance
Ext. Maint. (+ 2%)*
Ext. Maintenance (+ 4%)*
Customer-Specific Maintenance
SAP R/3 Enterprise 47x110
Mainstream Maintenance
Ext. Maint. (+ 2%)*
Ext. Maintenance (+ 4%)*
Customer-Specific Maintenance
Customer-Specific Maintenance
2010
2011
2012
2013
Mar
Mar
2009
Dec
Mar 2008
Mar
2007
This strategy is also valid for all industry-specific add-on applications based on the releases above.
Mar
2006
Customer-Specific Maintenance
Mar
2005
Ext. Maintenance (+ 4%)*
Dec
Ext. Maint. (+ 4%)*
Ext. Maint. (+ 2%)*
Dec
SAP R/3 3.1I – 4.6B
Jun
Mainstr. Maint.
Oct
SAP R/3 4.6C
Customer-Specific Maintenance
2014
2015
2016
* Overall payment is SAP Standard Support / SAP Premium Support fee plus additional fee of 2% or 4% of the maintenance base per year. © SAP AG 2007
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-507
Product Availability Matrix http://service.sap.com/pam
To continue, choose a product version
View in Service Marketplace: All product versions are displayed with general availability date and end of maintenance date.
© SAP AG 2007
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-508
Maintenance Management Unit Overview Diagram Maintenance Management Lesson 1: SAP Maintenance Strategy Lesson 2: Types of Corrections Lesson 3: Support Package Stack Strategy Lesson 4: Side-Effect Reporting Lesson 5: Support Package Content Analysis Lesson 6: Applying Support Packages Lesson 7: Maintenance Optimizer Lesson 8: HotNews Inbox
© SAP AG 2007
© SAP AG
E2E200
8-509
Types of Corrections
Correction Process ABAP
Java
Standard correction process
Emergency correction process
Support Package Stack SAP Kernel Patch ABAP Support Package
SAP Note Correction (ABAP)
Java Support Package Java Support Package Patch Java Single Patch (Fix)
© SAP AG 2007
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-510
−
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-511
•
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-512
Maintenance Management Unit Overview Diagram Maintenance Management Lesson 1: SAP Maintenance Strategy Lesson 2: Types of Corrections ABAP Corrections Java Corrections
© SAP AG 2007
© SAP AG
E2E200
8-513
Component Model and Maintenance
P1
Products
Release Support Package
Software Components
S1
D6
Packages D4
Objects
P2
O1
O2
D8
D5
(in ABAP, not the complete SC is shipped - only the changed objects)
S2
D7
D11
D9
D10
Notes
O3
© SAP AG 2007
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-514
SAP Note in the Service Marketplace
© SAP AG 2007
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-515
Correction Instruction: Changing a Function Module Old version 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_pat03 WHERE patch = iv_patch. ENDSELECT. IF sy-subrc <> 0. RAISE nothing_found. ENDIF. SELECT * FROM pat07 INTO TABLE t_pat07 WHERE patch = iv_patch. ENDFUNCTION.
New version 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 pat03 WHERE patch = iv_patch. ENDSELECT. IF sy-subrc <> 0. RAISE nothing_found. ENDIF. MOVE-CORRESPONDING pat03 TO es_pat03. SELECT * FROM pat07 INTO TABLE t_pat07 WHERE patch = iv_patch. SELECT * FROM pat08 INTO TABLE t_pat08 WHERE patch = iv_patch. CALL SCREEN 0100 STARTING AT 14 2. ENDFUNCTION.
© SAP AG 2007
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-516
Language dependent texts • DDIC objects •
© SAP AG
E2E200
8-517
Note Browser
The Note Browser gives you a list of all SAP notes Select all notes with implementation status “Completely implemented” Transaction SNOTE
GOTO
SAP Note Browser
© SAP AG 2007
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-518
ABAP Support Packages
http://service.sap.com/swdc
© SAP AG 2007
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-519
System Systems
Status: Version Information of ABAP
© SAP AG 2007
The version information of ABAP based systems can be reached via the Menu Bar: • System Status Button „Component information“
© SAP AG
E2E200
8-520
Maintenance Management Unit Overview Diagram Maintenance Management Lesson 1: SAP Maintenance Strategy Lesson 2: Types of Corrections ABAP Corrections Java Corrections
© SAP AG 2007
© SAP AG
E2E200
8-521
Component Model and Maintenance
P1
Products
P2
Release Support Package
Software Components
S1
D6
Packages
(in JAVA, the complete SC is Shippe. Packages are cumulative)
S2
D8
D11
(Fix) D4
Objects
O1
O2
D5
D7
D9
D10
O3
© SAP AG 2007
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-522
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-523
Java Fixes The smallest unit that can be delivered is the software
development component, which is shipped in a software development archive (SDA) A fix corrects a single error SDA-file fixes are used for preliminary correction in urgent cases or for releases prior to SAP NetWeaver 2004s Published on demand as attachment in SAP notes or customer messages Only apply fixes with guidance from SAP’s support. Apply the next higher support package stack instead Software Component Development Component 1
Development Component 2
Development Component 3
Development Component 3
Fix
© SAP AG 2007
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-524
Java Support Packages Java Support Packages: Include all corrections and updates in the period since the last support
package Support packages are delivered for software components. They are shipped as software component archives (SCA) Software component archives contain several software development archives Support packages are delivered at regular intervals as part of a support
package stack according to a schedule Java support packages are cumulative. That means each support package contains all of the predecessors SCA, SP20 SDA 1 SP18
SDA 2 SP20
SDA 3 SP16
SDA 4 SP17
SDA 5 SP20
© SAP AG 2007
© SAP AG
E2E200
8-525
Java Patches Java Patches (as of Netweaver 2004s): Like a regular support package, a patch contains a full
software component and is delivered as software component archive (SCA). A patch contains the latest regular support package plus all
fixes that were published since the release of the latest support package. It is published on demand. SCA, SP20, Patch 1 SDA 1 SP18
SDA 2 SP20
SDA 3 SP16
SDA 4 SP17
SDA 5 Fix
© SAP AG 2007
© SAP AG
E2E200
8-526
SAP Service Marketplace Java Patches and Support Packages are published on the SAP Service Marketplace, quick link /swdc
© SAP AG 2007
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-527
SAP Notes SAP Notes describe single bugs which are fixed in patches.
© SAP AG 2007
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-528
Component Info: Version Information of Java Systems http://:/sap/monitoring/ComponentInfo
Release 7.00 SP Level 10 Patch 1
© SAP AG 2007
The version information of a JAVA based system can be seen in the Component Information. http://:/sap/monitoring/ComponentInfo For each software component, the Version string shows Release, Support Package and Patchlevel.
© SAP AG
E2E200
8-529
Maintenance Management Unit Overview Diagram Maintenance Management Lesson 1: SAP Maintenance Strategy Lesson 2: Types of Corrections Lesson 3: Support Package Stack Strategy Lesson 4: Side-Effect Reporting Lesson 5: Support Package Content Analysis Lesson 6: Applying Support Packages Lesson 7: Maintenance Optimizer Lesson 8: HotNews Inbox
© SAP AG 2007
© SAP AG
E2E200
8-530
Support Package Stacks (SP Stacks) SAP releases sets of Support
Packages per product and quarter – the SAP Support Package Stacks (SP Stacks)
R/3 Appl.
Support Packages & patches
of SP Stacks must be used in the given combination, other combinations only apply for exceptional cases
ABA Basis Kernel
APO Appl. ABA
Higher quality and ensured
compatibility of included Support Packages Simplified download of
included Support Packages from a one page summary
Basis Kernel
BW Appl. ABA Basis Kernel
Accelerated application,
lower cost of operations and system maintenance
Q1
Q2
Q3
Q4
t
© SAP AG 2007
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-531
Support Package Stack Download Service Marketplace
quick link /sp-stacks Selection of an
application component implicitly includes underlying technology stack – Example: XSS
EP
Java
© SAP AG 2007
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-532
Selection of Platform
Operation System Unicode vs. non-Unicode Database
© SAP AG 2007
In the next step you have to enter your technology platform (operating system, database, unicode, 32-Bit or 64-Bit).
© SAP AG
E2E200
8-533
Save the Stack Definition XML File
Don’t forget to save the Stack Definition XML file!
© SAP AG 2007
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-534
SAPGUI and Kernel Version
Check minimum required SAPGUI version . Check recommended kernel version.
© SAP AG 2007
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-535
SP Stack Schedule SAP Service Marketplace, Link /SP-Stacks: http://service.sap.com/sp-stacks Note: These dates may change
© SAP AG 2007
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-536
Maintenance Management Unit Overview Diagram Maintenance Management Lesson 1: SAP Maintenance Strategy Lesson 2: Types of Corrections Lesson 3: Support Package Stack Strategy Lesson 4: Side-Effect Reporting Lesson 5: Support Package Content Analysis Lesson 6: Applying Support Packages Lesson 7: Maintenance Optimizer Lesson 8: HotNews Inbox
© SAP AG 2007
© SAP AG
E2E200
8-537
Side-Effects of Single Notes
© SAP AG 2007
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-538
Side-Effects Reporting: Calculation for SP Queues Side-Effect Report
SPy
SPx
Note
Version
73510 276432 23443 234234 655465 464564 456466 33535 223424 23223
SuppPackage 0012 0010 0001 0003 0005 0008 0001 0001 0002 0004
Version
Note Side-effect 376552
0003 0004
Note
Version
Version
SuppPackage ----------------------------------
Note Side-effect
776552
------------
743543 --------
...
343543
Example
0002 321254, ...
Queue Calculation: Side Effects that are solved within the same SP queue will be filtered
Individual calculation automatically Side 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 © SAP AG 2007
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-539
Side Effects Reporting Tool in the SAP Service Marketplace
© SAP AG 2007
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-540
Number of Known Side-Effects over the Time Number of Known Side Effects
Development Close
Internal Tests
Release of SP Stack
Customer Projects
Internal Messages
Customer Messages
Side effect Notes
Side effect Notes
Most bugs are fixed
© SAP AG 2007
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 sideeffects if you execute the reporting at a later point in time.
© SAP AG
E2E200
8-541
Maintenance Management Unit Overview Diagram Maintenance Management Lesson 1: SAP Maintenance Strategy Lesson 2: Types of Corrections Lesson 3: Support Package Stack Strategy Lesson 4: Side-Effect Reporting Lesson 5: Support Package Content Analysis Lesson 6: Applying Support Packages Lesson 7: Maintenance Optimizer Lesson 8: HotNews Inbox
© SAP AG 2007
© SAP AG
E2E200
8-542
Maintenance Management Unit Overview Diagram Maintenance Management Lesson 1: SAP Maintenance Strategy
Lesson 2: Types of Corrections Lesson 3: Support Package Stack Strategy Lesson 4: Side-Effect Reporting Lesson 5: Support Package Content Analysis Analysis of SAP Notes in Support Packages Custom Development Optimization Package
© SAP AG 2007
© SAP AG
E2E200
8-543
Get List of Notes from SAP Service Marketplace http://service.sap.com/swdc
Click on title to get the list of notes
© SAP AG 2007
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-544
List of Notes in a Support Package
© SAP AG 2007
Expand the list and download it.
© SAP AG
E2E200
8-545
Number of Notes per Software Component In this example, an R/3 Enterprise system was patched from Source Stack Level 18 to Target Stack Level 24. The number of notes per Software Component was as follows: SAP_APPL 15.969 SAP_BASIS 4.431 SAP_ABA 2.034 EA_APPL 1.704 EA_IPPE Total
81 24.219
© SAP AG 2007
This slide shows the number of notes per component of a specific support package stack.
© SAP AG
E2E200
8-546
Number of Notes per Application Component The application components with most changes are: BC Basis FI Financials CA Cross Application
4286 2297 1711
LO Logistics MM Material Management
1674 1667
CO Controlling PP Production Planning
1509 1340
SD Sales and Distribution XX Others LE Logistics Execution
1329 1315 1128
© SAP AG 2007
This slide shows the number of notes per application component.
© SAP AG
E2E200
8-547
Number of Notes per Application Sub-Component FI-AP-AP Accounts Payable FI-GL-GL General Ledger XX-CSC-IN Country Spec. India AP-MD-BP Business Partner MM-PUR-GFPurchasing XX-CSC-BR Country Spec. Brazil FS-BP Fin.Serv. – Bus.Part.
602 544 436 405 377 319 304
LE-SHP-DL Delivery Processing CO-PC-ACT Actual Costing FI-AA-AA Asset Accounting
287 284 280
Identify Relevant Components
© SAP AG 2007
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-548
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.
© SAP AG 2007
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-549
Notes by Category Each Note has a category. Most notes are in the category “Program Error”. Legal changes are most critical. A Program error
21.621
K FAQ
12
B Consulting
89
N Exit added
91
C Customizing
83
P Performance
388
D Advance development
240
R Release planning information
7
T Correction of Legal functions
867
E Special development
109 U Upgrade information
6
F Documentation error
87
W Workaround for missing funct.
51
G Translation error
215
X External error
14
H Legal change
294
Y Help for error analysis
24
I Installation information
21
Grand Total
24.219
© SAP AG 2007
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-550
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.
© SAP AG 2007
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-551
Maintenance Management Unit Overview Diagram Maintenance Management Lesson 1: SAP Maintenance Strategy
Lesson 2: Types of Corrections Lesson 3: Support Package Stack Strategy Lesson 4: Side-Effect Reporting Lesson 5: Support Package Content Analysis Analysis of SAP Notes in Support Packages Custom Development Optimization Package
© SAP AG 2007
© SAP AG
E2E200
8-552
Deliverables
Customer in advance of upgrade or reorganization project
Customer in upgrade or change (support package or transport import) project
Clearing Analysis
Upgrade / Change Impact Analysis
CDOP Control Center
Certified users*) in CDOP projects
Receivers
Custom Development Optimization Package
Start -Up WorkShop
RFC Basis 4.6C / WebAS 6.20 / 6.40 / 7.00 Enabling base technology General functionality, „middleware“ „Applications“
*) certified users by attendance of e-learnings
© SAP AG 2007
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-553
Upgrade/Change Impact Analysis Upgrade/Change Impact Analysis: Identification of relevant customer workbench objects Determination of SAP objects used in custom code Qualified determination of changed SAP objects in upgrade or support package Intersection between these two sets Display of workload (“hit objects“) for adaptation with supporting functionality
Control center Navigation and control of CDOP tasks
© SAP AG 2007
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-554
Upgrade / Change Impact Analysis - Systems CDOP Control Center
Analyis System
Reference System Comparision Changed SAP Objects by Upgrade, SP, Transport
SAP Objects Referenced by customer objects
© SAP AG 2007
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-555
Upgrade / Change Impact Analysis - Steps
© SAP AG 2007
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-556
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-557
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-558
Upgrade/Change Impact Analysis – Results
© SAP AG 2007
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-559
Solution Support Enablement Package (SEP) 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.
Packaged Tools:
BMC AppSight for Windows/.Net SAP Test Data Migration Server CA Wily Introscope SAP Custom Development Optimization Package SAP Reverse Business Engineer SAP Best Practices for Operations
Find more information at http://service.sap.com/sep © SAP AG 2007
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-560
Maintenance Management Unit Overview Diagram Maintenance Management Lesson 1: SAP Maintenance Strategy Lesson 2: Types of Corrections Lesson 3: Support Package Stack Strategy Lesson 4: Side-Effect Reporting Lesson 5: Support Package Content Analysis Lesson 6: Applying Support Packages Lesson 7: Maintenance Optimizer Lesson 8: HotNews Inbox
© SAP AG 2007
© SAP AG
E2E200
8-561
Three Steps to the New Support Package Stack
1
2
3
Download
Apply
Configure
© SAP AG 2007
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-562
Maintenance Management Unit Overview Diagram Maintenance Management Lesson 1: SAP Maintenance Strategy
Lesson 2: Types of Corrections Lesson 3: Support Package Stack Strategy Lesson 4: Side-Effect Reporting Lesson 5: Support Package Content Analysis Lesson 6: Applying Support Packages Applying ABAP Support Packages Applying Java Support Packages
© SAP AG 2007
© SAP AG
E2E200
8-563
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 mode One Add-on Delta Upgrade in SAINT can also be included in the queue
© SAP AG 2007
© SAP AG
E2E200
8-564
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 end Import 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 2007
© SAP AG
E2E200
8-565
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 2 Un-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 2007
© SAP AG
E2E200
8-566
Known Problems with Support Packages
© SAP AG 2007
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-567
Downtime Minimized Method Standard Process
Downtime-minimized Process
Preparatory and Test steps
Preparatory and test steps
Import steps during productive operation
Import steps during productive operation
Import steps during non-productive operation
Import steps during non-productive operation
Cleanup steps
Cleanup steps
© SAP AG 2007
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 nonproductive 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-568
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-569
Maintenance Management Unit Overview Diagram Maintenance Management Lesson 1: SAP Maintenance Strategy
Lesson 2: Types of Corrections Lesson 3: Support Package Stack Strategy Lesson 4: Side-Effect Reporting Lesson 5: Support Package Content Analysis Lesson 6: Applying Support Packages Applying ABAP Support Packages Applying Java Support Packages
© SAP AG 2007
© SAP AG
E2E200
8-570
Apply the Support Package Stack with JSPM
© SAP AG 2007
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\\\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-571
Support Package Handling
JSPM
Kernel Patch
SDM Patch
J2EE Server SDM Server
SDM Client API
*.SCA
Deploy Service
Inbox
SDMKIT.JAR
SAPEXE.SAR – DB-independent SAPEXEDB.SAR – DB-dependant
© SAP AG 2007
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-572
Java Support Package Manager (JSPM) Features Support Package Management: Validation of dependencies between Software Components and their Support 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
© SAP AG 2007
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-573
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 file Business downtime from the start of deployment Package validation takes place during normal operation Inform your users before starting deployment Restart of JSPM is required after the JSPM self-update Always as very first package in the deployment queue Validation result and import queue are retained Restart the deployment of remaining packages in the queue No further human interactions required
© SAP AG 2007
© SAP AG
E2E200
8-574
Maintenance Management Unit Overview Diagram Maintenance Management Lesson 1: SAP Maintenance Strategy Lesson 2: Types of Corrections Lesson 3: Support Package Stack Strategy Lesson 4: Side-Effect Reporting Lesson 5: Support Package Content Analysis Lesson 6: Applying Support Packages Lesson 7: Maintenance Optimizer Lesson 8: HotNews Inbox
© SAP AG 2007
© SAP AG
E2E200
8-575
Example: SAP ERP 2005 – Component View ABAP Components SAP ECC
Java Components
ABAP Add-On’s
Java Web Applications
(for NetWeaver AS ABAP)
LSO (FE) 6.0 SEM 6.0
SAP XSS 6.0
FINBASIS 6.0
LSO (CP) 6.0
E-Recruiting 6.0
Biller Direct 6.0
SAP Catalog 2.0
XECO 5.0
SAP ECC 6.0
cProject Suite 4.0
(Details see next slide)
WFM_Core 2.0
EP Content Business Packages
BI Content 7.0x
LSO (FE) 6.0 SEM 6.0
SAP SRM
Front End LSO (AE) 6.0 LSO (OP) 6.0 cProjects ECL Viewer
SAP Easy Document Management 6.0 SAPGUI 6.20/ 6.40 SEM Frontend Components
XI Content
(Available as ECC-Add-On and stand alone server)
XI Content for Applications
FINBASIS 6.0 E-Recruiting 6.0
SAP Solution Manager
OpenPS for MS Projects
BI Content
inclusive:
Additional Components
SAP SRM 5.5
ELSTER 2.0
SAP NetWeaver 2004s © SAP AG 2007
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-576
Better Handling of Customer Maintenance Processes Planning of maintenance Support Packages and Stacks HotNews
Administration
Display current level and recommended level
Approve and download
Provide transparency Import
Test
Release to production
© SAP AG 2007
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-577
Maintenance Optimizer – Technical Process Description NW BI
1 Check Versions nio r t lu ge So ana M
NW BI
6
SAP ERP
2 Select Files
e ic r v et e S ark e M lac P
Maintain Status 3 Confirm Files Download Basket (part of SMP)
5 4
Implement Support Packages
Download Files
Download Manager © SAP AG 2007
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-578
System-Demo
System-Demo
© SAP AG 2007
© SAP AG
E2E200
8-579
Create a New Maintenance Transaction (3/3) 1. Start transaction SOLUTION_MANAGER SOLUTION_MANAGER
2. Go to Change Management -> Support Package Stacks 3. Choose Maintenance Optimizer
© SAP AG 2007
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-580
Step 1: Plan Maintenance
2. You can add business partners and documents
1. Choose Product Version
3. Choose Continue
© SAP AG 2007
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-581
Step 2: Select Files
2. Add files to Download Basket
1. Go to area of chosen product version in SAP Support Portal
3. Choose Continue This step will be enhanced with an automatic calculation of the necessary files.
© SAP AG 2007
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-582
Step 3: Download Files
1. Go to Download Basket
3. Continue
2. Confirm files in Download Basket
© SAP AG 2007
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-583
Step 4: Perform Implementation
1. Set status of implementation to In Progress 3. Set status of implementation to Completed
2. Look for details and request side effect notes 4. Continue © SAP AG 2007
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-584
Step 4: Perform Implementation
© SAP AG 2007
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-585
Step 5: End Maintenance
Complete maintenance transaction
© SAP AG 2007
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-586
Maintenance Optimizer – Monitoring 1. Start transaction /n/tmwflow/maintenance 3.Choose Execute
2.Choose parameters
4.Results
© SAP AG 2007
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-587
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 Support Assign S-user for SAP Support Portal functionality or with the transaction AISUSER
© SAP AG 2007
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-588
Configure SAP Download Manager
© SAP AG 2007
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-589
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 installation Integration with Change Request Management (planning, reporting, monitoring) as a guided procedure Integration with Enhanced Change and Transport System (CTS+) and Software Lifecycle Management Tools Further information is provided in the SAP Service Marketplace under the link http://service.sap.com/solmanmopz
© SAP AG 2007
© SAP AG
E2E200
8-590
Maintenance Management Unit Overview Diagram Maintenance Management Lesson 1: SAP Maintenance Strategy Lesson 2: Types of Corrections Lesson 3: Support Package Stack Strategy Lesson 4: Side-Effect Reporting Lesson 5: Support Package Content Analysis Lesson 6: Applying Support Packages Lesson 7: Maintenance Optimizer Lesson 8: HotNews Inbox
© SAP AG 2007
© SAP AG
E2E200
8-591
SAP Launched Three New Note Service Offerings 1. SAP HotNews Contain solutions for customer problems with very high priority, such as systems standstills or data loss Allow customers to filter and display SAP HotNews for their chosen components
2. SAP TopNotes Inform you about 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
3. SAP FAQNotes Present the most frequently asked questions for particular topics with brief and 'to-the-point' answers Ideal place to start looking for a quick and easy answer before embarking on a full-blown search
© SAP AG 2007
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-592
Proactive and Reactive Channels Proactive Channel
Reactive Channel Support Desk Incident
SAP Service MP
System Monitoring e.g.
Incident
Service Desk/Incident Management
Monitoring Incident
Problem
Problem
Problem Management
Problem Management
Hot News
Program Errors (ABAP) Update Errors
Top Notes
Request and Commitment for Change • Emergency • Maintenance – reactive / proactive Notes Implementation
Application Management
Test and Implementation of Change • Note Assistant
Technology Team © SAP AG 2007
© SAP AG
E2E200
8-593
SAP HotNews Inbox in SAP Solution Manager Based on infrastructure (see prerequisites)
HotNews Planning
SAP HotNews Inbox (DSWP) Retrieve relevant HotNews from SMP*
Postpone HotNews for later administration
Set HotNews to not relevant (not applicable, read only)
Filter HotNews view Log activities
HotNews Processing
Create change request
Transaction Processing (CRMD_ORDER)
Check change request data
Approve change request for HotNews
Process change request – start standard “urgent correction process”
* SAP Service Marketplace © SAP AG 2007
© SAP AG
E2E200
8-594
Best Practice for HotNews and TopNotes Set up regular procedures to check for new HotNews: HotNews TopNotes
Weekly cycle 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 responsibles Choose components where a customer opened OSS calls in
last 3 – 6 months Get SAP Service Marketplace Newsletter weekly
© SAP AG 2007
© SAP AG
E2E200
8-595
Appendix
System Demo
© SAP AG 2007
© SAP AG
E2E200
8-596
Maintenance Management – SAP HotNews Retrieve SAP HotNews from SAP Service Marketplace (Transaction: DSWP, Operations area, Change Management tab, HotNews Inbox, New tab) Retrieve relevant SAP HotNews using Refresh button
© SAP AG 2007
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-597
Maintenance Management – SAP HotNews Filter settings in SAP HotNews Inbox (Transaction: DSWP, Operations area, Change Management tab, HotNews Inbox, New/Postponed/Not relevant tab) Filter displayed data according to your areas of responsibility
2
1
3
© SAP AG 2007
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-598
Maintenance Management – SAP HotNews Create change request for SAP HotNews (1/3) (Transaction: DSWP, Operations area, Change Management tab, HotNews Inbox, New tab) Create change request for selected SAP HotNews in order to apply for SAP HotNews installation for the respective system (here, TW2).
2
1
© SAP AG 2007
© SAP AG
E2E200
8-599
Maintenance Management – SAP HotNews 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
3
Fast Entry – SAP HotNews
4
Transcation Data/Context tab – Solution-specific information Including SAP Hot News (see Notes)
© SAP AG 2007
© SAP AG
E2E200
8-600
Maintenance Management – SAP HotNews Create change request for SAP HotNews (3/3) (Transaction: DSWP, Operations area, Change Management tab, HotNews Inbox, New tab) Change requests and their status can be viewed at any time
© SAP AG 2007
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-601
Maintenance Management – SAP HotNews Postpone SAP HotNews (1/2) (Transaction: DSWP, Operations area, Change Management tab, HotNews Inbox, New tab) Postpone SAP HotNews for administration at a later point of time
2
1
© SAP AG 2007
© SAP AG
E2E200
8-602
Maintenance Management – SAP HotNews Postpone SAP HotNews (2/2) (Transaction: DSWP, Operations area, Change Management tab, HotNews Inbox, Postpone tab) Comment on the reasons/background for postponing SAP HotNews to increase transparency
© SAP AG 2007
Comments are listed in chronological order. Log allows status change tracking for respective SAP HotNews
© SAP AG
E2E200
8-603
Maintenance Management – SAP HotNews Set postponed SAP HotNews back to New (Transaction: DSWP, Operations area, Change Management tab, HotNews Inbox, Postpone tab)
2
1 3
© SAP AG 2007
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-604
Maintenance Management – SAP HotNews SAP HotNews Set to Not Relevant (Transaction: DSWP, Operations area, Change Management tab, HotNews Inbox, 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.
2
1
© SAP AG 2007
SAP HotNews that are not relavant can be set back to status New
© SAP AG
E2E200
8-605
Maintenance Management – SAP HotNews 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.
© SAP AG 2007
Click on comment icon to see complete comment
© SAP AG
E2E200
8-606
Maintenance Management: Unit Objectives You should now be able to: 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 2007
© SAP AG
E2E200
8-607
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-608
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-609
8-4-2
© SAP AG
c) Select another note and set it to Not Relevant. Enter a comment. d) Check if your activities were logged in the folder Log. 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.
E2E200
8-610
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?
8-1-3
© SAP AG
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. Check the version information for the JAVA stack of system TT5 on the Component Info site. What is the URL? The URL is http://: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.
E2E200
8-611
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.
8-2-3
© SAP AG
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). 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.
E2E200
8-612
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
© SAP AG
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.
E2E200
8-613
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
8-614
© SAP AG
E2E200
8-615
Test Management
Introduction to E2E Change Control Management Solution Landscape Documentation E2E Change Diagnostics Netweaver Development Environments Enhanced Change and Transport System Transport Strategies Change Request Management Maintenance Management Test Management IT Reporting for Change Control © SAP AG 2007
© SAP AG
E2E200
9-616
Test Management 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
© SAP AG 2007
© SAP AG
E2E200
9-617
Test Management At the end of this unit, you will 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 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 2007
© SAP AG
E2E200
9-618
Test Management Unit Overview Diagram Test Management Lesson 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 2007
© SAP AG
E2E200
9-619
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 Acquisitions
Test effort
Continuous Improvements Functional Upgrades … IT inspired changes: Technical Upgrades Support Packages Notes ...
Business inspired changes
IT inspired changes
© SAP AG 2007
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-620
Testing in Projects – The V-Model Functional sign off
Validation
Functional Requirement, Business Case
Requirements Doc
OK
User Acceptance Test Functional Test Validation
Verification
Integration Test Integration Test Integration Test
Functional Design Business Blueprint Verification
Config Owner Test, can be automated Validation
Detailed (Technical) Design
Unit Test
Development Validation
Existing Business Processes
Regression Testing (automated)
© SAP AG 2007
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-621
executed and organized by the project test coordinator Customer sign-off is the final approval. •
© SAP AG
E2E200
9-622
Testing in Projects Implementation Project
Business Blueprint Doc Test Concept
Realization Development, Test
Final Preparation and Go Live
Testing & Bug Fixing is ~30% of total project effort
Review
Unit Test (Debugging)
Bug Fixing
Review
Integration Test
Test Case Development
Bug Fixing
Test planning
Business Blueprint
User Acceptance Test
Project Preparation
OK Functional sign off
Regression Test
System sign off OK
© SAP AG 2007
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-623
Regression Testing
Core Business Processes Business Scenario
Project Changes
Business Scenario
Process A42 Test
Process B32 Test
Process A43 Test
Process B33 Test
Process A44 Test
Process B34 Test
…. Business Scenario …. Project A Project B1
Blueprint Dev Test
Service Packs, Blueprint Dev Test
Patches, Notes Project B2 Project C
Blueprint Dev Test Blueprint Dev Test
Repairs Dev Test
Regression Test Test Automation (eCatt + 3rd party tool)
Functional OK sign off OK
System sign off
Approval Release Delivery © SAP AG 2007
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-624
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
© SAP AG 2007
In technical system tests, the complete infrastructure consisting of database, application server, frontends, network, printer, etc. is checked.
© SAP AG
E2E200
9-625
Performance Tests Performance Tests: Response time of important transactions Runtime 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.
© SAP AG 2007
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-626
Test Planning (1) How will testing be performed? Manual tests Automated test scripts
What tools can be used? Test Organization: SAP Test Workbench Solution Manager – Business Process Repository 3rd party tools like HP Quality Center
Test Automation: CATT - Computer Aided Test Tool eCATT 3rd party tools like Compuware, Mercury Quick Test Pro, Mercury Load Runner
For Textual Cases: Process descriptions Templates for test cases Test case review is useful (correctness, completeness, grade of details)
© SAP AG 2007
© SAP AG
E2E200
9-627
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 2007
© SAP AG
E2E200
9-628
Requirements for a test case description
Contents: Test case: Title: Description Preparation Execution Checking / expected result Extra notes
© SAP AG 2007
© SAP AG
E2E200
9-629
Test Management Unit Overview Diagram Test Management Lesson 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 2007
© SAP AG
E2E200
9-630
SAP Test Workbench – Overview Test Workbench
Management
Open Interface
eCATT 3rd-party test tools
Status information
Test Organizer
Migration
Management
CATT Status information
Test Management & Execution
Test Automation, Recording
© SAP AG 2007
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-631
Testing – Process in Detail Test analysis
Test package
Project structure with assigned test cases
Test plan
Collection of test cases
Selection of test cases
Project/business related e.g. Implementation CRM 4.0 Interaction center
Aim and time related e.g. for applying a specific Support Package
Test package Test package Test package Test package Test package
Assignment of test packages to testers
Testers
Test Execution
operation queue of a single tester
© SAP AG 2007
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-632
Testing – Create and Assign Test Cases
A test catalog is a directory structure to store test cases. In the Configuration phase, create a test catalog and assign test cases.
© SAP AG 2007
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-633
Testing – Generate Test Plans and Test Packages Systematic storage of test cases for testing business processes Administration of manual and automated tests Generation of project-specific test plans and test packages Assignment of testers, who will find the assigned test packages in their work lists
© SAP AG 2007
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-634
Test Execution
Access to user specific worklist Test execution in accordance with test case description Log of test results and status Creation of a Support Message, if necessary
© SAP AG 2007
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-635
Test Monitoring and Reporting
Detailed views of test progress and test results Graphics and reports for all test plans in a project Export of test results into office applications
© SAP AG 2007
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-636
Problem Ticket Handling
Administration of Problems during a test Detailed Analysis and Prioritization of Problems Assignment of processors via Test Coordinator
© SAP AG 2007
Testers can create Service Desk messages to track failed test cases.
© SAP AG
E2E200
9-637
Test Report (Transaction: STWB_2, menu Go to -> Test Report) Generation of a Test Report for one Test Plan MS Word Document containing all Test Plan information Enhanced traceability of test results Various selection and assembly options for Test Report
Microsoft Word Doc ument
Examples for usage of a test report: Formal acceptance of a test phase Documentation obligation in validated areas (FDA Compliance)
© SAP AG 2007
After a test phase, a test report can be created. This is often required in validated areas (FDA compliance).
© SAP AG
E2E200
9-638
Benefits of the SAP Test Workbench The SAP Test Workbench provides the following benefits: Guarantees reusability for manual and automated test cases Easy test case description and test result documentation Logging of who has tested what, when and with which result Test results are reproducible Support for systematic testing Well-designed monitoring possibilities for Test Manager (Status analysis) Simple handling
© SAP AG 2007
© SAP AG
E2E200
9-639
System-Demo
System-Demo
© SAP AG 2007
© SAP AG
E2E200
9-640
Test Management Unit Overview Diagram Test Management Lesson 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 2007
© SAP AG
E2E200
9-641
Additional Benefits of the SAP Solution Manager SAP Solution Manager:
Provides the business process structure as central repository for test cases Is a central system administration platform and provides RFC Connections to the satellite systems Provides integration with Service Desk, Change Request Management, Implementation
© SAP AG 2007
© SAP AG
E2E200
9-642
Testing in SAP Solution Manager Business Blueprint & Configuration Selected Business Scenarios Internet Sales: B2C Business Processes Business-to-Consumer
BC
Register in Web Shop Select Product Update Shopping Basket
Order Processing
Test Plan
Selected Business Scenarios
Central definition and preparation of test plans and packages. Assign test packages to Testers.
Internet Sales: B2C Business Processes Business-to-Consumer Register in Web Shop Select Product Update Shopping Basket
Testers find test packages in their personal Work-list and execute the test, for example, using eCATTs.
Order Processing
Create Order
Create Order
Process Order
Process Order
Check the status of your tests in the Status Info System.
© SAP AG 2007
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-643
Leverage Business Process Definition Assign test cases In 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).
© SAP AG 2007
© SAP AG
E2E200
9-644
Project System Landscape 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 obligatory define 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. © SAP AG 2007
© SAP AG
E2E200
9-645
Central Test Co-ordination SAP CRM
SAP APO
SAP R/3
Create Sales Order
Test Execution
Configure Products Availability Check Determine Conditions Credit Check Receive Order
Replicate Order Order Confirmation Maintain Status
Test Mgmt.
SAP Solution Manager
Example: Sales Order Processing
© SAP AG 2007
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-646
Integration with other Tools in SAP Solution Manager Solution Manager Test Workbench Management
Implementation Content Project Structure
eCATT Status information
Service Desk Issue Management
Test Organizer
Migration
Management
CATT Change Request Management
Status information
Test Management & Execution
Test Automation, Recording
© SAP AG 2007
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-647
Interface to HP Quality Center SAP Solution Manager Create Implementation Project
Business Blueprint (Draft)
HP Quality Center 0
Create Testing Project
Design Handover: • System Type • Business Blueprint • Transaction • General Doc • Project Doc • Status • Keywords • Graphics • Blueprint Lock • Requirements
2
1
Build initial Test Cases Structure Status
3 Business Blueprint (Final)
4 Finalize Test Case Structure
5
Status
Development
6 Implement Test Cases
Customizing Status UI Design
7 Test Execution
9 Status
Report Defect
Service Desk
0
Build Handover: • Logical Component • Status • Requirements • Config Lock (tbd) • Lock Requirement Tab
8 Document Results
Test Status Queries
11 Link Display Analysis
13 Close Implementation Project
10 Test Data Analysis
15
Close Project Cycle/ Release
12
Execute Handover: • Link to Requirement • Execution Results to SAP Solution Manager
14
© SAP AG 2007
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-648
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-649
Test Management Unit Overview Diagram Test Management Lesson 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 2007
© SAP AG
E2E200
9-650
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 records Test cases can be reused for later purposes. (e.g., Support Packages) Regression Testing Methodical approach to reduce costs and safeguard the software lifecycle process. © SAP AG 2007
© SAP AG
E2E200
9-651
What can be tested with eCATT
? Web Dynpro via Presentation Server
Server Business Logic
Database Table operations
Web AS
Client GUI
SAP GUI for Windows and Java
SAP GUI for HTML / external apps.
eCATT
Data Table
Cust. Table
© SAP AG 2007
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-652
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 Java The SAP application server The 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
© SAP AG 2007
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-653
Requirements for eCATT Support Package Level Each system where you want to test must have at least the following support package level: 4.6C: Support Package 32 4.6D: Support Package 21 6.10: Support Package 17 6.20: Support Package 03
Client Settings For each client in which you want to test, you must ensure that the CATT/eCATT flag is set to allow tests to run.
GUI Scripting In order to use the new GUI Scripting functions, the following settings have to be made: Profile parameter sapgui/user_scripting must be set to TRUE SAP GUI must be Version 6.20 with patch level =>18 and GUI Scripting installed © SAP AG 2007
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-654
An automated test script with eCATT Test configuration System data
400 Nr 0 0 5 Nr 20 6 Nr
Test instructions
Log
Archive
Test data
© SAP AG 2007
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-655
Loops
Script Language Elements
Applications
Conditions
Checks
Calculations
Reading Table Values InlineABAP
Customizing
© SAP AG 2007
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-656
Commands for Recording Applications
WebDynpro Allows you to record webdynprobased transactions
SAPGUI Allows you to record sequences of screens containing controls
FUN Calls a Function Module
Applications
An interface allows you to integrate test tools from third-party vendors with SAP eCATT
TCD Allows you to record and replay SAP Transactions
© SAP AG 2007
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-657
Pattern Function The Pattern function is similar to the statement pattern in the ABAP Editor. It allows you to build individual eCATT commands.
© SAP AG 2007
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-658
Test Automation – Effort Calculation Test effort (people days)
Test 1
Test 2
Test 3
Manual tests
Cumulated effort Break-Even
Automated tests
Initial effort for development of eCATT scripts
25 14
14 2,5
14 2,5
Adjustments and execution of eCATT scripts
Regular Software Maintenance / Transports (Support Packages, Customer Coding)
© SAP AG 2007
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-659
Test Management Optimization – Project Timeline Q4/2004
Q1/2005
Q2/2005
Q3/2005
Q4/2005
2006
Research
TMO
Phase 1
Test Frame Work
Pilot
Phase 1 Core Business Processes (class 1, 2)
Manual Regression Test
Test Framework (manual test cases)
eCatt Pilot
Phase 2 Test Automation
Test Automation Framework, eCatt
Phase 2 Automated Regression Test Core Business Processes (class 1)
© SAP AG 2007
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-660
System-Demo
System-Demo
© SAP AG 2007
© SAP AG
E2E200
9-661
Test Management Unit Overview Diagram Test Management Lesson 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 2007
© SAP AG
E2E200
9-662
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, DDICobjects). 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.
© SAP AG 2007
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-663
Run Inspection before and after project import
© SAP AG 2007
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-664
Select Syntax Check Generation
© SAP AG 2007
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-665
Create Object set – save object set with your search key
© SAP AG 2007
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-666
Run Inspection
© SAP AG 2007
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-667
Results of Inspection
HTML Document
© SAP AG 2007
An inspection returns a Check Result, from which you can derive another object set.
© SAP AG
E2E200
9-668
Test Management Unit Overview Diagram Test Management Lesson 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 2007
© SAP AG
E2E200
9-669
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 timewindows Heavy dialog activity Many concurrent users (possibly same/similar transactions) Which business processes? Load start page Logon Search for … View Results Logoff
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 available Christmas / seasonal business activities in addition to “average” business. © SAP AG 2007
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-670
What should be Monitored? SAP System Checks: Single Statistical Records R/3 work process overview 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 Utilization of SAP shared buffers and SAP memory Number of active users Error messages and warnings
© SAP AG 2007
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-671
Performance Analysis Tool /SDF/MON
© SAP AG 2007
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-672
What Should be Monitored? Operating System Checks: CPU utilization Memory utilization Disk statistics Network Adapters
Database Checks: Buffer Quality Lock wait situations Shared SQL Area Latches
© SAP AG 2007
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-673
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 GUI E-Business: It connects via the http / https protocol to a SAP application (e.g. Enterprise Portal)
© SAP AG 2007
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-674
Load Generation by External Tools
Controller
Load generator
Server (e.g. EP)
• Controls the test • Collects monitoring data
Backend (e.g. ERP)
Monitoring J2EE
Database
Monitoring CCMS Operating System
Monitoring DB Monitoring OS
© SAP AG 2007
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-675
SAP Loadrunner by Mercury
© SAP AG 2007
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-676
Test Management Unit Overview Diagram Test Management Lesson 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 2007
© SAP AG
E2E200
9-677
Setting up a Test Landscape
SAP Quality Asst.
Development
TDV
SDTU
/MYSAP/
TQA
Production B
Delivery
PRD
ZTDV
ZTDV
BB-Copy of B
BAK
Create a relevant test landscape by: Client Copy System Copy Manual Creation of Test Data SAP Test Data Migration Server
© SAP AG 2007
© SAP AG
E2E200
9-678
System Copy Procedure Advantages: Identical copy of the whole system, including repository
objects, client independent and client dependent data No downtime of production system is needed, as a backup can be used Split Mirror Technology supports fast system copies
Disadvantages: If the production system is very large, the test systems also
get very large Sensitive data is copied into the test system Settings need to be readjusted after the system copy Transports need to be re-imported into the test system Same client structure must be used in test system as in production system Version history is overwritten (in development systems)
© SAP AG 2007
© SAP AG
E2E200
9-679
System Copy Procedure with a Backup PRD
QAS
2) Re-Import missing transports 1) Backup
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. © SAP AG 2007
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-680
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
© SAP AG 2007
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-681
Change Tracking in SAP Solution Manager
© SAP AG 2007
SAP Solution Manager provides a tracking function, which automatically determines the delta transports.
© SAP AG
E2E200
9-682
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 © SAP AG 2007
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-683
Usage of Virtual Systems as Project Piece List
DEV
QAS
Recommendation: Copy the buffer for each project / release / GoLive
PRD
Virtual System VRP
Software Library CIC_3.01_ 15_03_2007
Maintcycle_ 30_03_2007
CIC_3.02_ 15_04_2007
© SAP AG 2007
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-684
Test Management Unit Overview Diagram Test Management Lesson 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 2007
© SAP AG
E2E200
9-685
SAP Test Data Migration Server TDMS: Provide representative application data (extract) from a productive system to non-productive systems
Non-productive systems
Focus: Refresh of an existing system Productive system
TDMS
Selection of data from production system by different scenarios like: Master data Company code “time slice” © SAP AG 2007
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-686
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 that have already been imported into the target system, but are missing in the source system must be re-imported.
© SAP AG 2007
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-687
Application of Different Reduction Scenarios Development System: Additional test client in development system – no interference with actual development client Master Data & Configuration (Creation of transaction data by testers) Time-Based reduction Alternative 1: with e.g. two months Alternative 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 data Test system with 30% of production data Training system with 10% of production data
© SAP AG 2007
The amount of test data that is copied can be selected flexibly.
© SAP AG
E2E200
9-688
SAP TDMS – Reduction of Data Volume
Client DB
Assumption: 80 - 90% of the production data is stored in 10 - 20% of client-dependent tables
Data volume reduction: 80% Transaction Data *
In order to reduce the overall volume, only some tables need to be reduced All other tables (master and configuration data) are migrated entirely
10% Master Data * 7% Config. Data * 3 % Admin- Data* * Estimate based on project experience
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)
© SAP AG 2007
© SAP AG
E2E200
9-689
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 © SAP AG 2007
The Test Data Migration Server is built on top of the Migration Workbench which is a proven and stable tool.
© SAP AG
E2E200
9-690
Facts and Figures System Recommendation: SAP WebAS 6.20, 6.40 or 7.00 Shipped as Extension of SAP Solution Manager 4.0 Minimum 4 CPU, 4 GB RAM, 20 GB HD
Supported Releases: SAP R/3 4.6C SAP R/3 4.7 mySAP ERP 2004 (ECC 5.0) mySAP ERP 2005 (ECC 6.0)
Pricing: Price is dependent on size of production DB License covers one production system and n non-production systems
Knowledge Transfer/Training: TZTDM3 (offered by SAP Education)
© SAP AG 2007
© SAP AG
E2E200
9-691
Solution Support Enablement Package (SEP) at a Glance
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.
Packaged Tools:
BMC AppSight for Windows/.Net SAP Test Data Migration Server CA Wily Introscope SAP Custom Development Optimization Package SAP Reverse Business Engineer SAP Best Practices for Operations
Find more information at http://service.sap.com/sep © SAP AG 2007
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-692
Test Management Unit Overview Diagram Test Management Lesson 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 2007
© SAP AG
E2E200
9-693
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 analysis Test cases that showed problems in previous test runs Areas which are affected by the new changes Most frequent transactions according to ST03 transaction profile
© SAP AG 2007
© SAP AG
E2E200
9-694
Categorization and Evaluation of Business Processes Complexity Very Complex
2
Complex
3
2
1
Standard
3
3
2
Low
High
20% of efforts
1
Prio 1
1
Example of possible Business Processes prioritization in terms of complexity and impact for business
Prio 2
80% of coverage
Prio 3
Very High
Impact
80% of efforts
20% of coverage
20% of efforts
80% of coverage
Selection of Business Processes for automation should be done taking several different aspects in mind
© SAP AG 2007
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-695
ST03 Transaction Profile
© SAP AG 2007
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-696
Key Aspects of Successful Test Strategy Centralized test coordination Definition of the test environment Management commitment and commitment for the test resources Categorization of the business processes in accordance with their
priority and availability requirements Planning of organizational and methodological actions to ensure the completeness of test cases Evaluation of the business processes and selection those of them you want to create automated test cases for (manual <> automated) Usage of dedicated tools for test administration, execution and monitoring
© SAP AG 2007
© SAP AG
E2E200
9-697
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 2007
© SAP AG
E2E200
9-698
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 TT4 is the Solution Manger system which contains all information about the system landscape. TT5 is a satellite system which is managed by TT4.
9-1
9-2
9-3
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? 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. 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
© SAP AG
Test the business process step Create Sales Order in CRM. This is an eCATT configuration. What is the total runtime for the test case? E2E200
9-699
Answer: _________________________________________________________
© SAP AG
E2E200
9-700
9-4
What was the runtime for the different transaction steps? Answer: _________________________________________________________ How is the result of the test run rated? Answer: _________________________________________________________ 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-701
Solutions Unit:
9-1
Test Management
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 to expand the Test Plan Structure. Now you see all test Expand All cases and transactions that are available. Select all test cases and transactions and click on the button Generate Test
9-2
Plan . Save as local object. 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 9-2-2
© SAP AG
Create Test Package . Select all available testcases and generate the test package. E2E200
9-702
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
9-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. 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-703
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 ( different screens that are executed.
). Observe the
The total runtime and the runtime for the different transaction steps can be seen in the eCATT Log Display.
9-4
The result of the test run is rated automatically. 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-704
© SAP AG
E2E200
9-705
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 of all test cases with their status.
© SAP AG
E2E200
to get a detailed list
9-706
IT Reporting for Change Control
Introduction to E2E Change Control Management Solution Landscape Documentation E2E Change Diagnostics NetWeaver Development Environments Enhanced Change and Transport System Transport Strategies Change Request Management Maintenance Management Test Management IT Reporting for Change Control © SAP AG 2007
© SAP AG
E2E200
10-707
IT Reporting for Change Control : Unit Content Content: Change Diagnostics Change Deployment Change Request Management Maintenance Management Test Management Solution Quality Reporting
© SAP AG 2007
© SAP AG
E2E200
10-708
IT Reporting for Change Control: Unit Objectives At the end of this unit, you will be 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 2007
© SAP AG
E2E200
10-709
IT Reporting for Change Control
Change Diagnostics
Test Management
Deployment
Solution Quality
Change Request Management
Maintenance
© SAP AG 2007
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-710
IT Reporting for Change Control IT Reporting for Change Control Lesson 1: Change Diagnostics Lesson 2: Change Deployment Lesson 3: Change Request Management Lesson 4: Maintenance Management Lesson 5: Test Management Lesson 6: Solution Quality Reporting
© SAP AG 2007
© SAP AG
E2E200
10-711
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
unit Inconsistencies in the parameter configuration within the
transport landscape and within the productive environment Completeness of landscape description in SAP Solution
Manager
© SAP AG 2007
© SAP AG
E2E200
10-712
Compare Multiple Instances
Missing value
Unchanged value
Additional value
Different value Additional value Missing value
© SAP AG 2007
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-713
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-714
Number of Parameter Changes
© SAP AG 2007
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-715
IT Reporting for Change Control IT Reporting for Change Control Lesson 1: Change Diagnostics
Lesson 2: Change Deployment Lesson 3: Change Request Management Lesson 4: Maintenance Management Lesson 5: Test Management Lesson 6: Solution Quality Reporting
© SAP AG 2007
© SAP AG
E2E200
10-716
Change Deployment KPIs for IT Reporting Goal: 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.
KPIs: Number of transports in the system per time unit Number of errors during the transports per time unit Modification level of the systems Consistency of the transport landscape
© SAP AG 2007
© SAP AG
E2E200
10-717
Transports into Production - Overview
PRD
QAS
DEV
© SAP AG 2007
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-718
Transport into Production During the Day Total DB Time [last month]
Workload per day, compared with number of transport requests.
Quality Risk 00
02
04
06
08
10
12
14
16
18
20
22
00
02
04
06
08
10
12
14
16
18
20
22
Transports [last six month]
500
400
300
Technical Analysis of the Transport Statistics show the risks to the current Change Schedule, due to many transport during high workload.
200
100
0
© SAP AG 2007
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-719
Source Systems of Transport Requests in Production
Source Systems
Number of transports
Date of first import
Date of last import
DEV
1.453
10.11.05
11.04.06
DE1
161
01.01.05
27.02.06
QAS
42
01.11.05
27.04.06
PRD
58
01.11.05
28.04.06
DE2
10
01.12.05
23.03.06
© SAP AG 2007
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-720
System Modification Level
Indicator
Value
Workbench Requests since System Installation
17.125
Customizing Requests since System Installation
14.737
Customer Objects
16.025
Modified Objects
2.558
© SAP AG 2007
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-721
Modified Objects by Application Component Component
Description
No. of objects
SD-MD-CM
Conditions
LO-LIS-DC
Data Collection
80
FI
Financial Accounting
73
SD-SLS
Sales
52
FI-LOC
Localization
48
SD-FT-PRO
Basic Functions
42
SD-MD-MM
Material Maintenance
29
BC-BMT-WFM
SAP Business Workflow
24
CA-GTF-TS
Technical Application Support
23
151
Sum
522
© SAP AG 2007
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-722
Customer Objects by Development Class Development Class
Description
Sum
YEDI
EDI
1545
YSD
Development SD
1377
YBC
Basis Global
1336
YMM
Development MM
854
YFI
Development FI
459
YPP
dummy
385
ZBC
Basis Regional
358
$TMP
Temporary Objects (never transported!)
320
YRS1
162
Z_BW
Business Warehouse developments
139
Other
Other Dev Classes
1327
Sum
8262
© SAP AG 2007
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-723
Most Frequently Changed Objects Object
Development Class
No. of Changes
LIMU REPS MYFDCF02
YEDI
106
LIMU REPS MYFDCF01
YSD
104
LIMU REPS MYFDCF04
YBC
98
LIMU REPS MYFDCF03
YMM
90
LIMU REPS SAPMYFDC
YFI
82
LIMU REPS MYFDCTOP
YPP
68
LIMU SHI6 YSSA-MENU
ZBC
68
LIMU SHI3 YSSA-MENU
$TMP
66
LIMU REPS MYFDCF07
YRS1
66
LIMU REPS MYFDCF08
Z_BW
64
© SAP AG 2007
These objects were changed very often. In these cases, the design might have been inadequate.
© SAP AG
E2E200
10-724
Errors During Import into Production - Last Six Months Return Code
No of Errors
0008
92
0012
3
0016
0
© SAP AG 2007
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-725
Object Compare Between Development and Production Category
Number of inconsistencies
Objects only in DEV
2.923
Objects only in PRD
143
Different Versions in DEV and PRD
2.481
© SAP AG 2007
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-726
Repository Comparison with Transaction SREPO
© SAP AG 2007
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-727
Customizing Comparison with Transaction SCU0
© SAP AG 2007
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-728
IT Reporting for Change Control IT Reporting for Change Control Lesson 1: Change Diagnostics Lesson 2: Change Deployment
Lesson 3: Change Request Management Lesson 4: Maintenance Management Lesson 5: Test Management Lesson 6: Solution Quality Reporting
© SAP AG 2007
© SAP AG
E2E200
10-729
Change Request Management KPIs for IT Reporting Goal: Change Request Management is the efficient and punctual implementation of SAP software changes, with minimal risks using standardized methods and procedures.
KPIs: Number of change requests per time unit and status Approval/realization time of change requests per priority and
category Number of urgent corrections compared with normal
corrections Number of rejected and approved change requests
© SAP AG 2007
© SAP AG
E2E200
10-730
Change Request Management Reporting: Urgent Corrections
To navigate to change transaction (here: urgent correction) double-click relevant entry in column Transaction ID
© SAP AG 2007
The result is a list of all urgent corrections in the last six months.
© SAP AG
E2E200
10-731
Number and Average Runtime of Change Requests Priority
Category
Very High
Normal
3
8,2
Urgent
15
1,8
Normal
50
12,4
Urgent
10
2,4
Normal
75
18,6
Urgent
1
4,9
Normal
5
19,3
Urgent
0
0
Normal
133
16,1
Urgent
26
2,2
High
Medium
Low
Total
Number
Average Runtime (Days)
© SAP AG 2007
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-732
Number and Rejected and Approved Change Requests Priority
Category
Very High
Approved
18
Rejected
2
Approved
60
Rejected
5
Approved
76
Rejected
10
Approved
5
Rejected
5
Approved
133
Rejected
22
High
Medium
Low
Total
Number
© SAP AG 2007
This analysis shows the number of rejected and approved change requests. 14% of all requests were rejected.
© SAP AG
E2E200
10-733
IT Reporting for Change Control IT Reporting for Change Control Lesson 1: Change Diagnostics Lesson 2: Change Deployment Lesson 3: Change Request Management
Lesson 4: Maintenance Management Lesson 5: Test Management Lesson 6: Solution Quality Reporting
© SAP AG 2007
© SAP AG
E2E200
10-734
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 guidelines Same maintenance level in the transport landscape through the
technology stack Frequency of planned maintenance
© SAP AG 2007
© SAP AG
E2E200
10-735
Overview of Productive Systems Inst. No.
Inst. Description
Product
Usage
First Go-Live
Rel.
20081864
BW call off
BW
Productive
01.05.2001
31I
20101300
WebAS
WEB AS
Demo
20131230
APO
APO
Productive
01.08.2003
31I
20141452
EBP Call-Off
SRM
Productive
01.09.2003
40B
120011917
R/3 Germany
R/3
Productive
01.01.1998
45B
120014830
R/3 Spain
R/3
Productive
20.08.1997
45B
120010708
R/3 Turkey
R/3
Productive
01.03.1998
40B
120014122
R/3 USA
R/3
Productive
21.01.1998
31H
120014123
R/3 GB
R/3
Productive
01.06.1998
45B
120019786
R/3 France
R/3
Productive
01.10.1998
45B
120019896
R/3 Italy
R/3
Productive
01.11.1998
40B
© SAP AG 2007
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-736
System History for a Transport Landscape Step
Target-Release
Date
Installation DEV
3.0F
1996
Installation PRD
3.0F
June 1997
Upgrade DEV
3.0F -> 3.1I
1998
Upgrade PRD
3.0F -> 3.1I
January 1999
Upgrade DEV
3.1I -> 4.6B
2000
Upgrade PRD
3.1I -> 4.6B
August 2000
Upgrade DEV
4.6B -> ERP 2004
April 2006
Upgrade PRD
4.6B -> ERP 2004
June 2006
System Copy PRD -> QAS
ERP 2004
14.07.2006
© SAP AG 2007
This table shows the system history of a transport landscape.
© SAP AG
E2E200
10-737
Maintenance Level in a Transport Landscape Component
Release
Level in DEV
Level in QAS
Level in PRD
EA-APPL
500
0005
0005
0005
EA-DFPS
500
0005
0005
0005
EA-FINSERV
500
0005
0005
0005
EA-GLTRADE
500
0005
0005
0005
EA-HR
500
0005
0005
0005
EA-IPPE
300
0004
0004
0004
EA-PS
500
0005
0005
0005
EA-RETAIL
500
0005
0005
0005
PI
2004_1_500
0008
0008
0009
PI_BASIS
2004_1_640
0009
0009
0010
SAP_ABA
640
0013
0013
0013
SAP_APPL
500
0009
0009
0009
SAP_BASIS
640
0013
0013
0013
SAP_BW
350
0013
0013
0013
SAP_HR
500
0009
0009
0009
ST-A/PI
01H_ECC500
0000
0000
0000
ST-PI
2005_1_640
0004
0004
0004
© SAP AG 2007
This table shows the different maintenance levels along the transport landscape. There should be no inconsistencies.
© SAP AG
E2E200
10-738
Age of Implemented Support Packages Component
Release
Level
Date of Support Package
ABA_PLUS
100
15
27.10.2005
EA-APPL
200
10
27.10.2005
EA-DFPS EA-FINSERV
200 200
10 10
27.10.2005
EA-GLTRADE EA-HR
200 200
10 31
EA-IPPE EA-PS
200 200
20 10
EA-RETAIL
200
10
27.10.2005 27.10.2005
PI
2004_1_470
9
01.08.2005
PI_BASIS
2004_1_620
10
01.07.2005
SAP_ABA
620
57
07.12.2005
SAP_APPL
470
25
27.10.2005
SAP_BASIS
620
57
07.12.2005
SAP_HR
470
50
21.12.2005
01E_R3_470
0
27.08.2004
003C_620
2
05.08.2004
600_620
0
ST-A/PI ST-PI WP-PI
27.10.2005 27.10.2005 21.12.2005 11.10.2005
© SAP AG 2007
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-739
IT Reporting for Change Control IT Reporting for Change Control Lesson 1: Change Diagnostics Lesson 2: Change Deployment Lesson 3: Change Request Management Lesson 4: Maintenance Management
Lesson 5: Test Management Lesson 6: Solution Quality Reporting
© SAP AG 2007
© SAP AG
E2E200
10-740
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 cases Number of failed and succeeded test cases in a test cycle Retention time of transport requests in the test system Number of incidents after the Go-Live of a change
© SAP AG 2007
© SAP AG
E2E200
10-741
Status Analysis – Test Plan Results Overview: Test status of the whole test plan
Overview : Test status on the scenario level
Overview : Test status on the process level
Test status on the test case level © SAP AG 2007
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-742
Testing Time in QAS - Test Time spent in Quality Assurance System
Number of transports
Transport requests in %
Intensive Testing: More than 1 day
1.091
47%
Short Testing: More than ½ hour but less than 1 day
360
16%
Insufficient Testing: Less than ½ hour
324
14%
No Testing: Less than 5 minutes
540
23%
© SAP AG 2007
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-743
Service Desk Messages after a Go-Live
© SAP AG 2007
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-744
IT Reporting for Change Control IT Reporting for Change Control Lesson 1: Change Diagnostics Lesson 2: Change Deployment Lesson 3: Change Request Management Lesson 4: Maintenance Management Lesson 5: Test Management
Lesson 6: Solution Quality Reporting
© SAP AG 2007
© SAP AG
E2E200
10-745
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 errors Average response time in dialog Availability – planned and unplanned downtime
© SAP AG 2007
© SAP AG
E2E200
10-746
SAP EarlyWatch Alert – Content System Configuration Performance Overview Workload Distribution SAP System Operations Hardware Capacity Database Performance Database Administration Trend Analysis © SAP AG 2007
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-747
Key Performance Indicators from EWA Area
Indicators
Value
Trend
System Performance
Active Users
462
up
Avg. Response Time in Dialog Task
580 ms
up
Max. Dialog Steps per Hour
35114
steady
Database Performance
Database Space Management
Avg. Response Time at Peak Dialog Hour 556 ms
up
Avg. Availability per Week
100 %
steady
Avg. DB Request Time in Dialog Task
271 ms
up
Avg. DB Request Time in Update Task
350 ms
up
DB Size
176.28 GB
steady
Last Month DB Growth
66.34- GB
down
© SAP AG 2007
This table shows important key performance indicators in various system areas.
© SAP AG
E2E200
10-748
IT Reporting for Change Control IT Reporting for Change Control Lesson 1: Change Diagnostics Lesson 2: Change Deployment Lesson 3: Change Request Management Lesson 4: Maintenance Management Lesson 5: Test Management Lesson 6: Solution Quality Reporting
System Errors Performance Availability
© SAP AG 2007
© SAP AG
E2E200
10-749
System Errors per Week (EWA) Date
Availability (%)
Program Errors (ABAP)
Update Errors
26.03.2006
99
312
71
02.04.2006
100
247
74
16.04.2006
97
194
160
23.04.2006
95
471
93
30.04.2006
100
431
86
07.05.2006
100
346
50
14.05.2006
100
331
77
© SAP AG 2007
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-750
History of ABAP dumps and Update Errors 4500 4000 3500
[number]
3000 2500 2000 1500 1000
15.09.2006
15.08.2006
15.07.2006
15.06.2006
15.05.2006
15.04.2006
15.03.2006
15.02.2006
15.01.2006
15.12.2005
15.11.2005
15.10.2005
15.09.2005
15.08.2005
15.07.2005
0
15.06.2005
500
[weeks] Program Errors (ABAP)
Update Errors
© SAP AG 2007
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-751
Category of ABAP Dumps
Top 5 ABAP Dumps in the last six months
No.
Category
TIME_OUT
3490
User
SYNTAX_ERROR
2177
Appl
DBIF_RSQL_SQL_ERROR
1284
IT
DYNPRO_SEND_IN_BACKGROUND
689
Appl
LOAD_PROGRAM_LOST
9
Transport
573
Appl
Quality Risk
MESSAGE_TYPE_X
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.
© SAP AG 2007
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-752
IT Reporting for Change Control IT Reporting for Change Control Lesson 1: Change Diagnostics Lesson 2: Change Deployment Lesson 3: Change Request Management Lesson 4: Maintenance Management Lesson 5: Test Management Lesson 6: Solution Quality Reporting System Errors
Performance Availability
© SAP AG 2007
© SAP AG
E2E200
10-753
History of Response Times
© SAP AG 2007
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-754
Workload Analysis
© SAP AG 2007
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-755
IT Reporting for Change Control IT Reporting for Change Control Lesson 1: Change Diagnostics Lesson 2: Change Deployment Lesson 3: Change Request Management Lesson 4: Maintenance Management Lesson 5: Test Management Lesson 6: Solution Quality Reporting System Errors Performance
Availability
© SAP AG 2007
© SAP AG
E2E200
10-756
System Availability Reporting – How to Get There Navigation to System Availability Reporting
© SAP AG 2007
© SAP AG
E2E200
10-757
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 2007
© SAP AG
E2E200
10-758
System Availability – Manual Maintenance
Standard options (can be modified)
Standard reasons (can be modified)
© SAP AG 2007
© SAP AG
E2E200
10-759
System Availability Reporting - Results
Availability Reporting result screen
© SAP AG 2007
© SAP AG
E2E200
10-760
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.
© SAP AG 2007
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-761
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 required Currently only available inside Service Level Reporting
© SAP AG 2007
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-762
•
additional output: Detected downtimes, unplanned downtimes, planned downtimes
© SAP AG
E2E200
10-763
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-764
Planned Outages by Category
© SAP AG 2007
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-765
Unplanned Outages by Category
© SAP AG 2007
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-766
IT Reporting for Change Control – Summary I Change Diagnostics: Number of changes in the parameter configuration per time unit Inconsistencies in the parameter configuration within the transport landscape
and within the productive environment Completeness of landscape description in SAP Solution Manager
Change Deployment:
Number of transports in the system per time unit Number of errors during the transports per time unit Modification level of the systems Consistency of the transport landscape
Change Request Management:
Number of change requests per time unit and status Approval/realization time of change requests per priority and category Number of urgent corrections compared with normal corrections Number of rejected and approved change requests
© SAP AG 2007
© SAP AG
E2E200
10-767
IT Reporting for Change Control – Summary II Maintenance Management: Comparison of the customer releases and support package level with
SAP guidelines Same maintenance level in the transport landscape through the technology stack Frequency of planned maintenance
Test Management:
Number of available test cases Number of failed and succeeded test cases in a test cycle Retention time of transport requests in the test system Number of incidents after the Go-Live of a change
Solution Quality Reporting: Number of ABAP dumps and Update errors Average response time in dialog Availability – planned and unplanned downtime
© SAP AG 2007
© SAP AG
E2E200
10-768
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 2007
© SAP AG
E2E200
10-769
Exercises Unit:
IT Reporting for Change Control
In this exercise, you can check your knowledge on IT Reporting for Change Control
This exercise consists of questions and answers.
10-1 Which areas are relevant for IT Reporting for Change Control? More than one answer is correct. Decide whether each answer is true or false. True
False Root Cause Analysis Test Management Interface Management Maintenance 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-770
Job Overview 10-3 Which KPIs are defined for Change Deployment More than one answer is correct. Decide whether each answer is true or false. 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-771
Solutions Unit:
Enhanced Change and Transport System
10-1 Which areas are relevant for IT Reporting for Change Control? More than one answer is correct. Decide whether each answer is true or false. 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? Please choose the correct answer. O
Import Buffer
X
Import History
O
Job Overview
© SAP AG
E2E200
10-772
10-3 Which KPIs are defined for Change Deployment More than one answer is correct. Decide whether each answer is true or false. 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
© SAP AG
E2E200
10-773