MISCELLANEUOS TOPICS

RUNTIME ANALYSIS

 The runtime analysis is an additional development workbench tool that is quite useful for analyzing performance of an ABAP / 4 Program or transaction. With this tool, the system can display information about:

·         Executed instruction

·         Accessed execution time.

·         Tables and Types of access.

·         Chronological execution flow

The runtime analysis tool creates lists that reveal expensive statements, summarize table accesses. Runtime analysis is specifically designed for tuning individual programs and transactions.

The Runtime Analysis tool measures ABAP/4 statements that are potentially expensive in terms of CPU time. The most significant of these are:

Statement used for database access like select.

Statement used for modularization such as module, perform, call function.

Internal table statements like append, collect.

Starting Runtime Analysis

·         From ABAP/4 development workbench select Test – Runtime Analysis.

·         From ABAP/4 editor, select utilities – more utilities – Runtime Analysis.

·         From ABAP/ source code screen, select Execute – Runtime Analysis.

·         From R3 screen, select System – Utilities – Runtime Analysis.

·         Entering Transaction code SE30 in the command field.

 Following screen is the initial screen for SE30 transaction.

On the initial screen, select the needed object you want to analyze i.e. program or transaction. Enter the name of the object. Click on execute. The system will execute the specified object and will generate a trace file or performance data file, which can then be analyzed when the transaction or program is finished.

Analyzing a performance data file

These files are created at operating system level and many times occupy large memory space, so be sure to remove the files, which are no longer needed.

 

To analyze the files:

·         Click on Analysis

·         Following screen is displayed

·         From GOTO option you can get overview of runtime analysis.

 

The options are as follows:

·         Hit List – Displays a list with the most system expensive instructions.

·         Tables – Displays the most important tables, the number of accesses and the time needed for the accesses.

·         Group hit list – Displays a list with the performed instructions classified by instruction type.

·         Call hierarchy – Presents a chronological listing with the flow of calls during the execution of a program.

 

During Runtime Analysis, the system measures the statements and stores these measurements in a performance data file. If you measure the same program or transaction several times, the data can vary. Many factors make it difficult to reproduce identical result. E.g., Network traffic.

 When you evaluate this file, the system displays the overview - Runtime Analysis Evaluation screen including a bar chart for total execution time. From this screen, you can analyze several types of information like:

 ·         Hit list: displays the list with the most `system-expensive’ instructions.

·         Tables: displays the most important tables, the number of accesses and the time needed for the accesses.

·         Group hit list: displays a list of performed instruction classified by its type.

·         Call hierarchy: presents a chronological listing with the flow of calls during the execution of program.

 SQL TRACE

The SQL trace is a tool, which allows displaying and analyzing the contents for the database calls, which are made by the reports and transactions written in ABAP/4. It monitors programs and transactions on the database level. With the help of this facility for every open SQL instructions, you can display, about which SQL Embedded (Declare, Open, Fetch) Statement have been executed, besides analyzing the system performance.

Steps to Creation

 

·         From R3 screen, select system –-> Utilities –-> SQL trace. Or Enter transaction ST05.

·         Click the trace on button.

·         Enter the user name whose programs are going to be traced.

·         Execute the program or transaction you want to trace.

·         Return to SQL trace initial screen and press the button SQL trace off. This switching off is necessary because if it is not done then SQL trace will trace each and every program executed by a particular user. And it is quite expensive in terms of memory and time of the system.

Analyzing The Trace File

To analyze the created trace, press the button list trace. Using this file you can see exactly how the system handles database requests. The first screen of the SQL trace data file displays each measured database requests, the application made. The trace file records when the request occurred and its duration.

 To display dictionary definition information about the table field, position the cursor on the table field and click on the DDIC info button. When this button is clicked, it displays system information like object name, table class, whether buffering is allowed or not i.e. information related to dictionary.

Explain SQL: This button provides the functionality, which includes the utility for providing detailed information about the SQL Operation Strategy followed by the underlying database system. You need to click on Explain SQL button. The system displays the execution plan for SQL statements. Here you can display the actual SQL statement like Select, which fields are being accessed, Table being accessed, all where conditions.

 ABAP/4 Display Gives you the actual ABAP/4 code.

 More information gives the detailed information for time, select statement, client, number of records selected etc. Replace variable will display the SQL statement with another variables.

Workbench Organizer & Transport System

SAP recommends three types of systems for implementation purpose

·         Development System

·         Test System

·         Production System

 Though number of systems used by an organization depends upon many factors such as size of implementation, budget etc. However even in the smallest installation, a second system is a must.

 Development system

Development system is the system where the actual development takes place. Normally the development is carried out for objects and these objects are original for these systems.

Test system

Also known as quality assurance system and are used to test the objects. You can test objects on development system also, but on Test System the object is tested against real data. When the tests are validated the development objects are transported to the production system.

 Production System

The production system is where the end user enters real business data and where the actual business runs. No development takes place in this system. You need to transfer the object from test system to production system.

 

The overall flow of objects can be understood in the following diagram:

Developer creates the objects in the development system, these objects are transported to the Test system to test them against the real data and when validated, these objects are transported to the Production System.

 

To transport these objects from one system to another, ABAP/4 development work bench provides the tool called Work bench organizer which is also used to manage activities that are important in the overall development environment.

Example, for these activities are.

·         The management and control of new development requests.

·         Modification of objects

·         Version management

In a distributed environment, workbench Organizer transports the development object between different SAP systems. In the following example, the objects are transported from the development system to production system.

 Workbench Organizer

The most puzzling topic of R3 system is intended to help functions for system development.

Concepts of workbench

·         Development objects: Workbench records and controls change to existing development objects as well as new objects. A development object is an object created in R/3 system. (Program, Screens, Function modules.)

·         Dictionary objects: Tables, Domains, Match code objects, Data Elements.

The workbench is fully integrated into the ABAP/4 development workbench.

·         Development Classes: A Development class classifies the objects belonging to the same development project.  When a user creates a object in R/3 system, the object needs to be stored in a particular development class. The development class are objects themselves.  In R/3 system you can store objects.

·         In local object i.e. object is stored in $tmp class and cannot be transported from one system to another.

·         User can assign his own development class and can be transported.

Transport System
 

·         Developers are in charge of creating or correcting data objects and will create change request, which can be for individual object or common request for a project.  When the change request is released the system performs transport

·         R/3 administrator is the person who sets up the transport system. This group works both at the R/3 application level and at the operating system level, using transport control (tp) program.

 

Change Request

A Change request is a list in the system, which mainly contains the object to be transported. It also contains the transport type, the request category and the target system.

When the change request is created either manually or automatically, the system assigns a number to it automatically. This number is known as change request number.

The format of this number is normally

K

E.g., DD1K<900002>

Where DD1 is System Identification Number (SID)

K is keyword

The number is automatically generated by system and starts with 900001.

The change request records all modifications made to development object.

When the changes are made and the change task (will be discussed) has been released, the change request can be released.

SEO9 transaction

Or

Tools -> ABAP/4 W.B -> overview -> W.B. organizer

Will display and check all the change requests.

Tasks

A task in the workbench organizer is an activity in which user either creates an object or modifies the same. In workbench organizer, task can be either development or repair task.

 A task is related to single user while change request contains tasks belonging to different users. You cannot transport task as such, but as a part of request. Each task is associated with task number, which is similar to change request number.

Usually, when a development work starts, a system administrator or project manager creates a change request to define tasks for all users involved in the project. Later, user starts modifying objects or create new object. Once user finishes his task, they must release them. A change request can be released for transporting, only when all tasks under the same change request are released.

 Objects included in task become locked against other development work on the same object.

Version Management
 
ABAP/4 workbench and the organizer provide a version management for all the objects in the system. With version management user can compare current version object and object with the previous version.

 To display the version for a object,

Locate your object through the change request number of workbench organizer. Click on the object and from menu.

Or

Utilities à display version.

It displays what has been modified and who did it.

Version management is important for developers also as it allows user to compare previous programs with the current one.

Transport

A transport means the process of moving something from one place to another. In R/3 system this ‘something’ means change request. To transport the objects you need to create the change request. It can be done with the help of workbench organizer. Transport System and workbench organizer are closely linked to each other.

An object original is a development object that has been created in the system in which you are working.

Suppose you transport object Zsus001 to another system, Zsus001 is object original for system DD1. If anyone tries to modify the program, he will be making repair to it, provided he has access key for the same. R/3 system offers this security measure to ensure that development object remain consistent for all system, thus preventing parallel work on the same objects. Correction of objects and development of objects can be only in original system.

The difference between Repair and Correction is as follows:

·         If you modify an object in a system in which it is created, you are making Correction to it.

·         If you modify an object in a system in which it was not created, then you are making Repair task.

Releasing Tasks and Request

When new development or correction is complete, developer must release their task and request.

To release a task:

·         Find a task from the Workbench initial screen.

·         Position the cursor over the task.

·         Click on the release button

A request is released by either system Administrator or Project Managers, once all the tasks are released