Skip to content
Mar 15 15

ABAP Dynamic Programming – Part 2

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

Tony CecchiniAnthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 20 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.

 

ABAP Dynamic Programming Techniques

OK, lets pick up from last month where we attempted to accurately define what Dynamic Programming. We said … Dynamic programming is the use of special programming constructs that enable you to use selected features of data and/or operations at runtime that cannot, for various reasons, be determined at compile time.

Lets keep this definition in mind as we begin this discussion on DYNAMIC Programming Techniques.

Using a Dynamic Table Names

Let begin by creating a very simple program that will display table names to the user and when clicked on, the user is presented with the number of rows in the table. Look at the code below

REPORT ztony.
DATA: tabname  TYPE tabname,
      count    TYPE i.

START-OF-SELECTION.
WRITE: / 'EBAN', / 'MARA', / 'VBAK'.

AT LINE-SELECTION.
READ CURRENT LINE LINE VALUE INTO tabname.
SELECT COUNT(*) FROM (tabname) INTO count.
WRITE: 'The table', tabname(7), 'contains', count, 'entries.'.

We have manufactured the “Requirement” that the user will NOT KNOW THE TABLE NAME at compile time, but will at runtime. This is exactly what our definition above states will require us to make use of Dynamic Program Techniques.

The program, at the event line-selection, will take the content of the selected line and read it into the field tabname. In the SELECT statement, the name of the database table is not specified statically. Instead, the clause from (tabname), denotes that the name of the database table is to be read from the variable tabname and substituted into the SELECT statement. So when the SELECT statement is executed, the field tabname is parsed for a valid name of a database table.  If tabname doesn’t contain a valid name, an exception occurs.

OK, lets keep evolving this little program… let’s say instead of the total count of records, we actually want the rows returned. OK, now we are talking about SELECTING rows into a work-area. But wait! We don’t know which table the user will choose, so how can we TYPE the appropriate work-area? We can, trust me. First we need to learn a little about Generic Types and Field-Symbols. But, I’ll even go up a level of abstraction and ask, what the heck is a TYPE?

ABAP Types

ABAP is a hybrid programming language with a type system that reflects both the runtime-event-oriented and the object oriented programming models. Object types (e.g.,classes and interfaces) and value types (e.g., structures and tables) are integrated into one type system and share the same namespace.

Think of types as blueprints for a house. Blueprints provide descriptions of houses. Types are just descriptions of data. This analogy provides an easy way to distinguish between types and data.

Generic Types

A type is defined as “a set of properties that apply to all data of this type,” while data is a sequence of bytes in the memory of the program. A type that contains the complete description required to create data is called a concrete type. In contrast, a generic type is only a partial description of data — for example, the length is not defined within the type. Since additional information is needed to fully describe the data, you cannot create data from a generic type.

Well by using Generic Data Types like ANY, or DATA we can create DATA REFERENCES. We can construct an appropriate work area via the command CREATE DATA. It allows you to create data objects with a dynamically specified type at runtime.

But before we start coding, we need to understand another ABAP construct, the Field-Symbol (cue the music..Da..Da…Da..Daaaaa) read more…

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest
Feb 16 15

ABAP Dynamic Programming – Part 1

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

Tony CecchiniAnthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 20 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.

 

ABAP Dynamic Programming Techniques

We have all seen it…..

Dynamic ABAP


Some of us have been around 20+ years and still don’t REALLY understand it. Imagine how a fresher feels when they encounter this form of code. Now I can hear the old timers here screaming it just NOT necessary to code this way and what does it buy you anyway? Well, this is exactly what I intend to look at in this series. All manner of DYNAMIC ABAP and DYNAMIC OPEN SQL. If nothing else it will be a good place for freshers to look when they encounter this madness… lets go!

Dynamic Programming Concepts and Benefits

What exactly is ABAP dynamic programming, and why is it so beneficial? Fundamentally, dynamic programming is used in almost every program, but the extent varies. Most programs consist of both dynamic and static parts. In this sense, programs are rarely black and white — most are shades of gray. Perhaps the best way to answer that question is to contrast dynamic with static programming.

In this context, dynamic and static apply to the data and/or operations performed on the data within a program. Static properties of data or operations are those characteristics that are known and fixed at compile time. They are explicitly defined in the program source code and will not change during runtime. In contrast, dynamic properties of data or operations are the characteristics that are not known or fixed at compile time. Instead, they are defined by the values of parameters that are passed to the program at runtime. read more…

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest
Jan 10 15

ABAP Database SQL Analysis Using The Performance Trace – Part 2

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

Tony CecchiniAnthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 20 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.

Which SQL Database Accesses Cause the Highest Load?

Picking up from last month, we will look at how to use the ST05 Performance Trace Tool to solve performance issues. Remember you’ve ruled out deficiencies in the system setup, mishandling by users, or the need for parallel processing, then you need to revisit your code and see if the source of your performance problem is hiding there in your SQL commands.

Central to any database access performance analysis is an understanding of which accesses cause the highest load. It’s only logical that this is where you concentrate your efforts. In order to identify which tables are excessively accessed, Performance Trace enables you to aggregate all accesses by the names of the tables. By summing up all the request times, you can see which accesses to which database tables are causing the highest database loads.

For instance, I will use SE16 and read table MSEG with no key fields entered and use the ST05 trace to record the SQL. As you would expect this takes a minute. Her is the output of the display trace below. By following the menu path Trace List=>Summarize Trace by SQL Statement or hitting SHIFT+F8 you can see the summary.

ST05 Summary Menu Path 

After activating the Summarize Function, you will see a list with the information aggregated for each table. The screen shot below displays a list that is already sorted by time to identify the database tables with the highest loads.

ST05 Summarized

Obviously in our example the MSEG read was the highest. But in your trace, the high load might be caused by the number of accesses, the amount of read data, or by expensive SQL statements. Pick the highest loads, and focus on these first.

OK, then what?

read more…

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest
Dec 21 14

ABAP Database SQL Analysis Using The Performance Trace – Part 1

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

Tony CecchiniAnthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.

 

Performance Problems Come in a Variety of Flavors

There are many reasons for slow execution of a transaction or a report. Sometimes there are general system problems. Sometimes users use the program in a way it was not designed for. Sometimes the nature of the application and workload calls for parallel processing. And sometimes the source of the performance issue can be traced back to your ABAP code, mainly the construction of your OPEN SQL Definition.

While there are many reasons other than database performance that could be causing the performance problem, this blog series will focus on just this aspect.  If you’ve ruled out deficiencies in the system setup, mishandling by users, or the need for parallel processing, then you need to revisit your code and see if the source of your performance problem is hiding there in your SQL commands.

Lets agree now that all programs perform numerous accesses to the database, so this should be considered thoroughly. For example, selections that are not supported by a suitable index can have long (very long!) runtimes. This not only potentially impacts the running programs themselves, but is also an encumbrance to all users, as they have only limited access to the database if it is blocked by some long-running selections.

Analyzing Database Access Activities with Performance Trace

If you found (or have assumed) that the long runtime is caused by database accesses, use the Performance Trace tool (transaction ST05) for further analysis. With Performance Trace you can record all accesses to the database coming from the instance.

As you can see in the steps below, you typically start the trace in one session (1), start the program you want to test in another session (2), switch off the trace after the end of the program (3), and then analyze the recorded data (4).

ST05 Sequence of Steps

 Let’s take a look at the start screen of the Performance Trace tool. Before we examine the details of using this tool, it is important to note the following considerations:

- Performance Trace records only the information coming from the work processes on the same instance. Consequently, if you are using Remote Function Calls (RFCs) or asynchronous updates in your program, the database accesses from these modules will not be recorded if they are executed on other instances.

- Performance Trace can be used by only one user at a time on each instance. Before using the trace, please make sure that it is currently switched off and not already in use. You can see this by the “Trace Status at the bottom of the start screen.

ST05 start screen

 

- The trace information is written to a file of a fixed size. If the size limit of the file is reached, the oldest data is overwritten. Therefore, it is possible that the trace information of a long running program will be incomplete and you will only see the most recent data. Data from older traces remain in the trace file only until the space is required for new trace information.

As you can see in the screen shot above, there are five different trace modes for the performance trace:

SQL Trace covers all database accesses.
Enqueue trace covers all enqueue operations.
RFC Trace covers all RFC communications from and to the instance
Buffer trace covers all accesses to the table buffers on the instance.
HTTP Trace covers response time end to end, time spent for execution on the server, Bytes sent and recieved, and time for data transfer both sent and received. (e.g. If you were connected via CITRIX and wanted to trace)

read more…

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest
Nov 17 14

What’s New in ABAP 7.02 and 7.03 – Part 3

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

Tony CecchiniAnthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company  headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation,  implementation, upgrade, and training assistance to   companies. Anthony has over 17 years of  experience in SAP R/3 business process analysis and SAP systems integration. His  areas of expertise  include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro  development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.

SAP NetWeaver Application Server ABAP

SAP NetWeaver Application Server ABAP provides highly valuable innovations with SAP NW 7.02 and 7.03, they cover a wide range from language and tool enhancements to UI technologies and services, but don’t be concerned you can still rely on your existing ABAP skills and easily extend to emerging technologies like In-Memory, Cloud and Mobile.

As promised this month we’ll take a look at Floor Plan Manger for Web Dynpro , The “Business Rule Framework Plus” and SAP Stream work.

Floorplan Manager for Web Dynpro ABAP

Lest start with some background

Floorplan Manager is a framework that you can use to create and configure Web Dynpro applications in Web Dynpro ABAP. You can use the Floorplan Manager configuration editor to combine application-specific views of one or more business applications to a new Floorplan Manager application. Floorplan Manager gives you the following advantages:

read more…

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest