Sie sind auf Seite 1von 104

IBM Global Business Services

IBM Global Business Services

IBM Global Business Services IBM Global Business Services Production Quality ABAP Workshop © Copyright IBM Corporation

Production Quality ABAP Workshop

© Copyright IBM Corporation 2007

© IBM Corporation 2013

IBM Global Business Services

IBM Global Business Services

IBM Global Business Services IBM Global Business Services ABAP DATA Dictionary © Copyright IBM Corporation 2007

ABAP DATA Dictionary

© Copyright IBM Corporation 2007

© IBM Corporation 2013

OVERVIEW

Delivery Class Data Browser /Table view Maintenance Technical Settings Table Maintenance Generator

Accessing the ABAP Dictionary

Use Transaction Code SE11 to access the ABAP Dictionary

Data Dictionary
Data
Dictionary

CREATION OF TABLE THROUGH TRANSACTION SE11

CREATION OF TABLE THROUGH TRANSACTION SE11

DELIVERY CLASS

The delivery class controls the transport of table data when installing or upgrading, in a client copy and when transporting between customer systems.

CLASS A:

Application Table (Master and Transaction Data).

Master data is data which is frequently read, but rarely updated. E.g. customer

master, material master. Transaction data is data which is frequently updated. E.g. sales order, purchase order.

Logically tables of delivery class A are not transported hence no CTS is assigned.

CLASS C: Customizing table.

Customizing data is data which is defined when the system is initialized and then rarely changed .e.g. company codes, document types.

Logically tables of delivery class C are transported hence CTS is assigned.

DATA BROWSER/TABLE VIEW MAINT

DATA BROWSER/TABLE VIEW MAINT :

Through this option we can insert data into the table. There are 3 options. DISPLAY/ MAINTENANCE ALLOWED WITH RESTRICTION : Through this option we can insert, delete, update data into the table through TABLE MAINTENANCE GENERATOR . DISPLAY/ MAINTENANCE ALLOWED : Through this options we can directly insert the data into the table through Utilities table contents create entries.

DISPLAY/ MAINTENANCE NOT ALLOWED : Through this option we can neither insert the data into the table directly nor through TMG . Only we can insert the data into the table programmatically using the SQL statement update, delete etc.

TECHNICAL SETTINGS OF A TABLE

TECHNICAL SETTINGS OF A TABLE

DATA CLASS

DATA CLASS: The data class defines the physical area of the database (for ORACLE the TABLESPACE) in which your table is logically stored. If you choose a data class correctly, your table will automatically be assigned to the correct area when it is created on the database.

For custom tables we use the data class USER. The other classes are used by SAP standard tables.

BUFFERING

Buffering Database Tables:

Buffering a table improves the performance when accessing the data records contained in the table. The table buffers reside locally on each application server in the system.

BUFFERING (Contd.)

You must define whether and how a table is buffered in the technical settings for the table. There are three possibilities here:

Buffering not permitted: We must not buffer a table if the table data is frequently modified.

Buffering permitted but not activated:

Buffering activated: Generally custom data are buffered with full buffering or generic buffering.

BUFFERING (Contd.)

The buffering type defines which table records are loaded into the buffer of the application server when a table record is accessed. There are the following buffering types:

Full buffering: All the records of the table are loaded into the buffer when one record of the table is accessed.

Generic buffering : When a record of the table is accessed, all the records having this record in the generic key fields (part of the table key that is left-justified, identified by specifying a number of key fields) are loaded into the buffer.

Single-record buffering: Only the records of a table that are really accessed are loaded into the buffer.

BUFFERING (Contd.)

Which Tables should be buffered?

Only transparent tables and pooled tables can be buffered. Cluster tables cannot be buffered.

Character data types must be assigned to all key fields of buffered tables.

BUFFERING (Contd.)

When Tables shouldn’t be buffered?

The data read by the application must always be up-to-date. Delays caused by the synchronization mechanism cannot be accepted.

The table data is frequently modified. In this case the cost of synchronization could be greater than the gain in performance resulting from buffering. Roughly speaking, it does not make sense to buffer a table if more than one percent of the accesses to the table are modifying accesses.

TABLE MAINTENANCE GENERATOR

Follow menu path Utilities -Table maintenance generator from transaction SE11. Specify the Authorization Group. (E.g. &NC& for skipping any Authority Check) Click ‘one step’ maintenance type.

Give the Overview Screen as ‘9000’. (You can specify any Screen Number beginning with 9)

Now, hit the Create Button to create the maintenance view for the table. Specify the Development Class and CTS when prompted for.

Specify a Function group. (If you don’t have a Function Group already, then open transaction SE80 in another session and create a Function Group)

We can also give a new function group Also remember to set the ‘Display/Maintenance allowed’ value in the table attributes.

TABLE MAINTENANCE GENERATOR (Contd.)

TABLE MAINTENANCE GENERATOR (Contd.)

TABLE MAINTENANCE GENERATOR (Contd.)

Only one maintenance screen is processed during extended table maintenance. The entries are displayed in list
Only one maintenance screen is
processed during extended table
maintenance. The entries are displayed
in list form on this screen
TABLE MAINTENANCE GENERATOR (Contd.) Only one maintenance screen is processed during extended table maintenance. The entries

TABLE MAINTENANCE GENERATOR (Contd.)

TABLE MAINTENANCE GENERATOR (Contd.)

TABLE MAINTENANCE GENERATOR (Contd.)

TABLE MAINTENANCE GENERATOR (Contd.)

TABLE MAINTENANCE GENERATOR (Contd.)

TABLE MAINTENANCE GENERATOR (Contd.)

TABLE MAINTENANCE GENERATOR (Contd.)

Changes are recorded by the standard recording routine. If there are individual routines, they supplement the
Changes are recorded by the
standard recording routine. If
there are individual routines,
they supplement the standard
routine.

TABLE MAINTENANCE GENERATOR (Contd.)

Changes are recorded by individual event routines, if defined, or not at all.
Changes are
recorded by individual
event routines, if
defined, or not at all.

Parameter T code for table :

Go to transaction se93 to attach a T code to TMG
Go to transaction se93 to
attach a T code to TMG

Parameter T code for table : (Contd.)

To create a parameter T code we have to choose the Parameter transaction
To create a
parameter T code we
have to choose the
Parameter
transaction

Parameter T code for table : (Contd.)

Parameter T code for table : (Contd.)

Database Index

An index helps to speed up selection from the database. An index is a sorted copy of selected

database table fields.

The primary index is always automatically created in an ABAP based SAP system. It consists of the

primary key fields of the database table. This means, for each combination of the index fields exists a

maximum of one record in the table. This kind of index is called a UNIQUE index.

Creating a secondary index

You can use the transaction ABAP Dictionary Change → Indexes

...

→ Create to create an index. To

make the index unique, select UNIQUE. To specify the fields that will comprise the index, choose

"Choose fields". Then save and activate the index.

Using an index consisting of several fields

Even if an index consists of several fields, you can still use it when only a few of the fields actually

appear in the WHERE clause. The sequence in which the fields are specified in the index is important.

You can only use a field in the index if all of the preceding fields in the index definition are included in

the WHERE condition.

An index can only support search criteria which describe the search value positively, such as EQ or

LIKE. The response time of conditions including NEQ is not improved by an index.

Database Index (continued)

Optimal number of fields for an index:

An index should only consist of a few fields; as a rule, no more than four. This is because the index has to be updated each time you change its fields in a database operation.

It is worth creating a secondary index when:

You want to select table entries based on fields that are not contained in an index, and the response times are very slow. The EXPLAIN function in the SQL trace shows which index the system is using. You can generate a list of the database queries involved in an action by entering Transaction ST05 and choosing Trace on → Execute action → Trace off → List trace. If you execute the EXPLAIN SQL function on a EXEC, REEXEC, OPEN, REOPEN or PREPARE statement, the system returns a list containing the index used in the database query.

The field or fields of the new secondary index are so selective that each index entry corresponds to at most 5% of the total number of table entries. Otherwise, it is not worth creating the index.

The database table is accessed mainly for reading entries.

Fields to include in an index:

Include fields that are often selected and have a high selectivity. In other words, you need to check the proportion of the table entries that can be selected with this field. The smaller the proportion, the more selective the field. You should place the most selective fields at the beginning of the index.

Database Index (continued)

If all of the fields in a SELECT statement are contained in the index, the system does not access

the data a second time following the index access. If there are only a few fields in the SELECT

statement, you can improve performance significantly by including all of these fields in the index.

You should not include a field in an index if its value is initial for most of the table entries.

Note:

Whenever you change table fields that occur in the index, the index itself is also updated.

The amount of data increases.

The optimizer has too many chances to make mistakes by using the 'wrong' index.

If you are using more than one index for a database table, ensure that they do not overlap.

The value NULL is not stored in the index structure of some database systems. The consequence

of this is that the index is not used for that field.

Since indexes are derived entirely from data already in the database, you can delete them

without data being lost.

Note that, in certain circumstances, the database system may have to update the index

corresponding to any data changes, which takes time. Index. Analysis of tables with respect to

index can be done from transaction DB05.

Typical logical steps within an ABAP executable programs

Design the selection screen for taking the inputs and do the validations of the entered inputs. Also do the necessary data filtrations.

Read the data from database table or file in the presentation/application server into internal tables.

Do the necessary data manipulations, calculations and collate the data into a final internal table.

Produce the final output (display the report, upload/download file).

Events

INITIALIZATION.

What does this event do?

It is used for assigning initial values to variables/constants of different data types.

The Different ABAP Predefined Data Types

Type

b

c

d

f

i

Value Area

Initial Value

  • 0 to 255

0

Any alphanumeric character

" " for every position

  • 8 user-defined alphanumeric characters; Only values in the format

 

YYYYMMDD that are permitted as date entries according to the calendar rules are valid: YYYY (year): 0001 to 9999, MM(month): 01 to 12, DD (day): 01 to 31

"00000000"

Floating point numbers are displayed internally with 16 decimal places according to the IEEE-754 standard (double precision). Valid values are -1,7976931348623157EE+308 to -2,2250738585072014EE-308 for the negative area, the value zero, and +2,2250738585072014EE- 308 to +1,7976931348623157EE+308 for the positive area. Both validity areas are extended in the direction of zero through demoralized numbers after IEEE-754.

0

-2.147.483.648 to +2.147.483.647

0

The Different ABAP Predefined Data Types (Contd.)

Type

n

p

string

s

Value Area

Initial Value

Any alphanumeric characters, however, valid values are only the digits 0 to 9

"0" for every position.

The valid length for packed numbers is between 1 and 16 bytes; two decimal places are packed into one byte, whereby the last byte only contains one place and the plus/minus sign; after the decimal separator, up to 14 decimal places are permitted. Depending on the field length len and the number of decimal places dec, the following applies for the value area: (-10^(2len -1) +1) / (10^(+dec)) to (+10^(2len -1) -1) /(10^(+dec)) in steps of 10^(-dec). Values in between this range are rounded off.

0

as for type c

empty string of length 0

-32.768 to +32.767

0

The Different ABAP Predefined Data Types (Contd.)

Type

Value Area

Initial Value

t

6 user-defined alphanumeric characters; the only valid values are numbers that are interpreted as a time specification in the 24-hour clock format HHMMSS. SAP recommends to exclusively use 00 to 23 hours for HH (hours) and 00 to 59 for MM (minutes) and 00 to 59 for SS (seconds).

"000000"

x

hexadecimal characters 0-9, A-F

hexadecimal 0

xstring

as for type x

empty string of length 0.

Set the default values of Parameters

parameters: p_date type sy-datum default sy-datum + 30.

We will get syntactical error here since the default offset should be only

string. Hence in this case we can solve our problem in the following way:

parameters: p_date type sy-datum. initialization. p_date = sy-datum + 30.

Steps for declaring an internal table/work area

1.Type Declaration.

First Method

types: begin of ty_cepc, bukrs type bukrs, prctr type prctr, datbi type datbi, kokrs type kokrs, end of ty_cepc.

Second Method

types: begin of ty_cepc, bukrs type cepc-bukrs, prctr type cepc-prctr, datbi type cepc-datbi, kokrs type cepc-kokrs, end of ty_cepc.

Steps for declaring an internal table/work area (Contd.)

2. Declaration of table type.

types: ty_t_cepc type standard table of ty_cepc.

3.Declaration of table/work area.

data: t_cepc type ty_t_cepc, wa_cepc type ty_cepc.

Selection-screen manipulation

In every report generally we have a selection-screen . The selection-screen is needed for user interaction , within this selection screen we can dynamically modify the screen elements as well as we can validate the screen input and provide appropriate message .

DYNAMIC MODIFICATION OF SCREEN

In AT SELECTION-SCREEN OUTPUT event we dynamically modify the screen, e.g. if we want to suppress the low or High value box of a select-options we can use this event.

The following is the code for dynamic modification of screen. This event occurs before the selection-screen appears.

select-options : s_matnr for mara-matnr . at selection-screen output . loop at screen . If screen-name = 'S_MATNR-HIGH'. screen-active = 0 . modify screen . endif. endloop .

VALIDATION CHECKING OF THE INPUT

In AT SELECTION-SCREEN event we can validate the user input also we can do data filtration . This event triggers after the selection screen appears .

The following is the code for data validation .

We can use the SELECT SINGLE clause if we have the full set of primary key in our hand if we don’t have the full set of primary key then we use the SELECT UPTO 1 ROW clause

parameters : p3_kunnr type kna1-kunnr . data : v_kunnr type kunnr . at selection-screen . select single kunnr into v_kunnr from kna1 where kunnr = p3_kunnr. if sy-subrc <> 0. message e398(00) with p3_kunnr 'enter valid customer no'. endif .

Selection-screen manipulation (Contd.)

When we use select-options in background a table namely select- options is generated .

we can see the content of the table in Debugging mode, it actually consist of 4 fields namely

1)

sign

2)

option

3)

low

4)

high

Sign

Meaning

I

Include the values

O

Exclude the values

Selection-screen manipulation (Contd.)

Option

Meaning

EQ

Equal to

LT

Less than

GT

Greater than

LE

Less than equal to

GE

Greater than equal to

BT

Between

NE

Not equal to

Selection-screen manipulation (Contd.)

Suppose for example we have a select option as following:

SELECT-OPTIONS: so_matnr FOR v_matnr. A so_matnr internal table is created as shown below:

Selection-screen manipulation (Contd.) Suppose for example we have a select option as following: SELECT-OPTIONS: so_matnr FOR

SEARCH HELP IN ABAP

A search help describes the flow of an input help. The search help can only take effect using a mechanism that assigns the search help to this field. This mechanism is called the search help attachment to the field.

Attaching a search help to a field has an effect on the field's behavior. It is therefore considered to be part of the field definition.

The input help (F4 help) is a standard function of the R/3 System. It permits the user to display a list of possible values for a screen field. A value can be directly copied to an input field by list selection.

The fields having an input help are shown in the R/3 System by the input help key to the right of the field. This key appears as soon as the cursor is positioned on the corresponding screen field. The help can be started either by clicking on this screen element or with function key F4.

If the number of possible entries for a field is very large, you can limit the set of displayed values by entering further restrictions.

HOW TO ATTACH SEARCH HELP IN ABAP

A search help can be attached directly to a field of a structure or table. The definition of this attachment is analogous to that of a foreign key.

If a field has a check table, its contents are automatically offered as possible values in the input help. The key fields of the check table are displayed.

If you are not satisfied with the described standard display of the data of the check table, you can attach a search help to the check table. This search help is used for all the fields that have this table as check table.

Attaching a search help to a check table (or a data element) can result in a high degree of reusability.

START OF SELECTION

This is the event where we retrieve the data from the database table . There are different ways by which we can fetch the data .

INNER JOIN.

FOR ALL ENTRIES.

In case of inner join it is recommended that we should use not more than 3 tables for performance issue.

We generally use FOR ALL ENTRIES clause but before that we should ensure that the table is not initial (empty). Otherwise if the internal table is empty then it will scan all the data in the dbtable from which we are retrieving the data so performance is again degraded here.

SELECT ENDSELECT

versus

SELECT……INTO TABLE

Whenever we select data from database table using select endselect the data selection flow consists of the following path which is recursive loop:

Presentation server-->application server--->database server.

Hence when we use the select endselect the performance is degraded.

But in the case of select into table the flow is only once (back and forth) so the performance is better in this case as compared select endselect.

Collating all the individual internal tables into a final internal table

Case 1.

Consider a simple example that we have two internal tables say t_makt and t_mara with fields and data as shown below.

Collating all the individual internal tables into a final internal table Case 1. Consider a simple
Collating all the individual internal tables into a final internal table Case 1. Consider a simple

Collating all the individual internal tables into a final internal table (Contd.)

Now we want to collate these two internal tables into a final table t_final which looks like the following.

Collating all the individual internal tables into a final internal table (Contd.) Now we want to

Collating all the individual internal tables into a final internal table (Contd.)

We can populate the final table t_final in the following way:

LOOP AT t_mara INTO wa_mara. READ TABLE t_makt INTO wa_makt WITH KEY matnr = wa_mara-matnr. IF sy-subrc EQ 0. wa_final-matnr = wa_mara-matnr. wa_final-mtart = wa_mara-mtart. wa_final-maktx = wa_makt-maktx. APPEND wa_final TO t_final. ENDIF. ENDLOOP.

Collating all the individual internal tables into a final internal table (Contd.)

Case 2.

Now in this case instead of combining the two individual internal tables (t_mara and t_makt) into a final internal table (t_final) we want to add the fields of internal table t_makt into another already existing table t_mara.

Case 2 (Contd.)

In this Case the logic should be as follows:

Declare the internal table t_makt with the fields to be selected from database table MAKT whereas declare the internal table t_mara with the fields to be selected from database table MARA plus the fields from t_makt.( the internal table t_mara should contain the fields of final internal table (t_final) of the previous case).

Initially for t_makt select the data from database table MAKT. For t_mara select the data from MARA table (the other fields remain blank).

Now populate the blank fields of t_mara by reading from the internal table t_makt.

The code for data selection and modification

START-OF-SELECTION. *********logical step 1******************** SELECT matnr mtart FROM mara INTO TABLE t_mara WHERE matnr IN so_matnr. IF sy-subrc <> 0. MESSAGE i004. LEAVE LIST-PROCESSING. ENDIF.

The code for data selection and modification (Contd.)

*********logical step 2******************** IF NOT t_mara[] IS INITIAL. SELECT matnr maktx FROM makt INTO TABLE t_makt FOR ALL ENTRIES IN t_mara[] WHERE matnr = t_mara-matnr.

ENDIF. IF sy-subrc <> 0. MESSAGE i005. LEAVE LIST-PROCESSING. ELSE.

SORT t_makt BY matnr. ENDIF.

The code for data selection and modification (Contd.)

*********logical step 3*********************** ***********method 2***************************

* LOOP AT t_makt INTO wa_makt. * LOOP AT t_mara INTO wa_mara WHERE matnr = wa_makt-matnr. *

wa_mara-maktx = wa_makt-maktx.

MODIFY t_mara FROM wa_mara TRANSPORTING maktx. * ENDLOOP.

*

* ENDLOOP.

*Note:

*This method(loop under loop) is highly not recommended Due to performance issues hence we use the method 1 ,described in the next slide.

The code for data selection and modification (Contd.)

*********logical step 3*********************** ****method 1********************************** LOOP AT t_mara INTO wa_mara. READ TABLE t_makt INTO wa_makt WITH KEY matnr = wa_mara-matnr BINARY SEARCH. wa_mara-maktx = wa_makt-maktx. MODIFY t_mara FROM wa_mara TRANSPORTING maktx. ENDLOOP.

***********************************************

The code for data selection and modification (Contd.)

Note 1:

In this case instead of modify if we use append then t_mara will look like below since an append adds a line to the internal table.

The code for data selection and modification (Contd.) Note 1: In this case instead of modify

The code for data selection and modification (Contd.)

Note 2:

In the above modify statement if we omit the addition TRANSPORTING maktx then all the corresponding fields are modified which is not required in our case since the fields' matnr and mtart remains the same and need not be modified. Hence only the third field maktx is modified using the addition TRANSPORTING maktx.

The code for data selection and modification (Contd.)

Note 3:

In the READ TABLE statement above it's a good practice that we use the BINARY SEARCH addition for the sake of improving performance but before this it is mandatory that we SORT (ascending or descending depending on the requirement) the internal table that we are reading.

In case we are reading an internal table using multiple key fields then the order in which we must SORT the table should match with the sequence specified in the READ TABLE statement.

The code for data selection and modification (Contd.)

For example if we have :

READ TABLE t_vbpa INTO wa_vbpa WITH KEY vbeln = wa_vbap-vbeln posnr = wa_vbap-posnr BINARY SEARCH.

In this case before the READ TABLE statement, t_vbpa should be first sorted by vbeln and then by posnr as shown below.

The code for data selection and modification (Contd.)

SORT t_vbpa BY vbeln posnr. LOOP AT t_vbap INTO wa_vbap. READ TABLE t_vbpa INTO wa_vbpa WITH KEY vbeln = wa_vbap-vbeln posnr = wa_vbap-posnr BINARY SEARCH. wa_vbap-kunnr = wa_vbpa-kunnr. MODIFY t_vbap FROM wa_vbap TRANSPORTING kunnr. ENDLOOP.

For All Entries (FAE)

For All Entries is an SQL syntax in ABAP to support array selects How to efficiently write a “FOR ALL ENTRIES” in ABAP:

1) The driver table cannot be empty. This would cause one full table scan.

2) In general, keep the driver table as small and unique (in regards to the fields that would be needed for referencing in the FAE) as possible. If duplicate entries are not deleted, identical data is read unnecessarily from the database.

3) If FAE is used, the selected field list must be a superset of all the key fields of the database tables used in SQL. This is absolutely required to avoid data loss since the DB interface in R/3 returns unique sets of the result set to the application program. Failing to ensure this may cause problems when you want to get all records from a database table that match a certain condition.

4) Avoid using FAE on a small DB table (like config tables). This could potentially cause full table scans for each FAE packet. Even if it does index range scan, it is better to get data from the small DB tables by individual selects without the use of FAE.

For All Entries (FAE)

5) Always use FAE in conjunction with a DB index otherwise it would cause multiple full table scans

(one table scan for each DB packet) or multiple inefficient index range scans

 

6) The first field(s) of the DB index should refer to the fields of the FAE driver table in the SQL

WHERE clause.

7) FAE works best when retrieving a small percentage of data from a Database table. When a large

percentage of data is needed, consider getting data out of the DB table without FAE implementation,

and then do additional filtration in your application.

MESSAGES

The following are the message available in ABAP .

Message type

Short description

Displaying position

Colors

S

Success

Bottom of the selection screen

Green

I

Information

Appeared as pop up box

 

A

Abbend

Appeared as pop up box

 

E

Error

Bottom of the selection screen

Red

W

Warning

Bottom of the selection screen

Yellow

MESSAGES (Contd.)

S--- Success --- A success message does not necessarily mean that an action was successful; It just determines the placement of the message and does not restrict the user from going on to the next screen.

I ----- Information ---- This message is displayed on the current screen in a dialog box . The user cannot make any changes to the values in the current screen , After pressing the ‘ Enter ‘ key on the dialog box the user will be taken to the next screen (further processing is allowed) .

A-------- Abend ---- The Abend message is displayed on the current screen in a dialog box , the user cannot make any changes to the values on the current screen , after

pressing the ‘Enter key’ on the dialog box the transaction will be terminated .

MESSAGES (Contd.)

W------- Warning--- The warning message is displayed at the bottom of the current screen , the user can make changes to the values of the current screen , but does not have to make any changes .

E---- Error --- The error

message is displayed at the bottom of the screen . The user

must make changes to the values on the current screen. After pressing the ‘Enter key’ on the current screen , the user will be taken to the next screen only if the appropriate correction is made on the current screen .

MESSAGES (Contd.)

It is recommended that we should use an ERROR message in SELECTION-SCREEN (for SELECTION-SCREEN validation) to ensure that we provide valid inputs before proceeding further.

In START-OF-SELECTION we should use INFORMATION message and not ERROR message because using the ERROR message will not allow the user to navigate to the previous screen (selection screen) to make necessary input changes.

After the information message we must also use the 'LEAVE LIST-PROCESSING' command in order to stop further execution so that before processing further we make the necessary changes.

Utility of using text elements:

While writing our codes we must use text elements instead of hard coded text.

This becomes mandatory when an entire code is to be translated to some other language.

For example consider that a code is written in English and now we want to translate it into Spanish.

We go to GOTO-->TRANSLATION and enter the original language and target language.

Doing this will translate the code to the target language if the language is available on the server but the hard coded text will remain as it is.

Hence for the hard coded texts:

First we must create text element (GOTO-->TEXT ELEMENTS or double click on the hard coded text) and assign the hard coded texts to different text numbers.

After that on the ABAP Text Elements screen GOTO-->TRANSLATION select the target language after which we get a screen where we can enter the equivalents of the original texts in the target language so that it is reflected when we open our code in the target language.

Utility of using text elements: (contd)

Utility of using text elements: (contd)

Additional Program Documentation

->Go to->Documentation->Click 'Edit Documentation' in documentation popup->Document-->Upload.

OR

->Go to->Documentation->Click 'Edit Documentation' in documentation popup->Go to-->Change Editor.

Here You can add what ever you want to show in your documentation.

Debugging :

On entering the debugging mode we see the following screen.

Debugging :  On entering the debugging mode we see the following screen.

DEBUGGING : (CONTD)

F5: Single Step: Executes the report line by line. This is useful if the user wants to see the program execute one line at a time.

F6: Execute: Processes all of the steps associated with one line of code. For example, one line of code may be a call to a subroutine. Execute will process that line without showing all of the activities inside the subroutine

DEBUGGING : (CONTD)

DEBUGGING : (CONTD)

DEBUGGING : (CONTD)

For e.g. initially the cursor was in line no. 29 and on pressing f6 the cursor moves directly to line 32 i.e., it executes the entire block of codes inside the subroutine validate plant at one go.

F7: Return: Returns the user to where the calling program resumes control after a called routine/function call etc.

F8: Continue: Processes all statements until a breakpoint or the end of the program is reached. If no breakpoints exist, the system will execute the report in its entirety without

stopping.

DEBUGGING : (CONTD)

Importance of WATCHPOINT :

Suppose that while troubleshooting a particular code, instead of analyzing and executing step by step or manually setting a breakpoint we want the program to stop execution or a breakpoint to be set when a certain condition is fulfilled for example when a variable achieves a particular value or loses a particular value.

Eg. In the debugging mode of our code the current value of SY-SUBRC is 0.

Case1: Now we want the program flow to stop when SY-SUBRC changes to any other value so we set a watch point as follows:

Go to debugging mode---->break/watch points ----> watch points--->create.

After that we get a popup where we can enter the variable name (in this eg. it is SY- SUBRC).

DEBUGGING : (CONTD) TO SET WATCHPOINT

DEBUGGING : (CONTD)

TO SET WATCHPOINT

DEBUGGING : (CONTD) TO SET WATCHPOINT

DEBUGGING : (CONTD)

Case2: If we want we want the program flow to stop when SY-SUBRC changes to a particular value say 4 then we must click on the No Additional Condition button and enter the additional condition (SY-SUBRC = 4) on the Free Condition Entry as shown below:

DEBUGGING : (CONTD)

DEBUGGING : (CONTD)

DEBUGGING : (CONTD)

BREAKPOINT :

It is also possible to set breakpoints at certain ABAP Commands.

For instance we enter an invalid input at any of the selection screen inputs and on doing so an error message is thrown. Now we wish to go to that part of the code which is responsible for throwing this message. This can be made possible by using Breakpoints at ABAP Commands.

DEBUGGING : (CONTD)

DEBUGGING : (CONTD)

DEBUGGING : (CONTD)

SAVING & LOADING DEBUGGER :

Whenever we keep our code in the debugging mode without using it then after sometime (timeout) the debugging session expires and consequently all the breakpoints/watch points that we have saved also expires. Hence in order to avoid this we can save the debugger before leaving the debugging session.

PATH:

Debugger------->debugger session------->save.

DEBUGGING : (CONTD)

DEBUGGING : (CONTD)

DEBUGGING:(CONTD)

DEBUGGING:(CONTD)

DEBUGGING: (CONTD)

Similarly we can load the debugger session that we have saved when we want. PATH:

Debugger------->debugger session------->load PATH:

DEBUGGING: (CONTD)

DEBUGGING: (CONTD)

SYSTEM LANDSCAPE:

Landscape is like a layout of the servers or some may even call it the architecture of the servers.

 A typical system landscape looks like the following: Development Testing/QA server Server Production server Preproduction
 A typical system landscape looks like the following:
Development
Testing/QA server
Server
Production server
Preproduction
server

SYSTEM LANDSCAPE: (contd.)

Development Server: We create our objects (reports/smart forms/data dictionary objects etc) in this server and then transport it to test server.

Testing/QA server: Different types of testing are performed here:

SYSTEM LANDSCAPE : (CONTD)

Preproduction server: This is optional. If this server is present then SPT (Stress Performance testing) and Cutover testing is done here.

Production server: This is the last/ most refined client where the user will work after project GO LIVE. Any changes/ new development is done is development client and the request is transported to production.

A request will flow from Dev->Qual->Prod and not backwards.

DEMO SYSTEM LANDSCAPE :

MENU PATH : TRANSACTION …. STMS

OVERVIEW----> TRANSPORT ROUTE

SYSTEM LANDSCAPE: (contd.)

SYSTEM LANDSCAPE: (contd.)

PACKAGE

A package is a logical folder kind of thing that contains a group of logically related development objects.

When entering a configuration/creating a development object, the SAP will prompt the user for a Change Request.

If the user already has an outstanding Change Request that he/she would like to place the customizing/development change in, the “Own Requests” button can be selected. This will provide the user with a tree structure view of all requests with which that user is associated. From there, the user may select the appropriate request in which to include the customizing/development change.

By selecting the “Create Request” button, a new Change Request will be generated, and a Task within the new request will be generated.

TESTING:

A) Unit testing: ABAP Unit is a test tool integrated in the ABAP runtime environment that you can use for executing module tests - that is, for checking the functions of code sections in a program .

Unit testing is done in bit and pieces. Like e.g. in SD standard order cycle; we do have 1- Create Order, 2-Delivery, 3-Transfer Order, 4-PGI and 5-Invoice. So we will be testing 1,2,3,4 and 5 separately one by one using test cases and test data. We will not be checking and testing any integration between order and delivery; delivery and Transfer Order; Transfer Order and PGI and then invoice.

B) Integration testing : A software system is composed of one or more subsystems, which are composed of one or more units (which are composed of one or more modules). Integration is the process of building a software system by combining subsystems into a working entity. Integration of subsystems should proceed in an orderly sequence. This allows the operational capabilities of the software to be demonstrated early and thus gives visible evidence that the project is progressing

Integration testing focuses on testing multiple modules working together. It tests the reliability and functionality of groups of units (modules) that have been combined together into larger segments. The most efficient method of integration is to slowly and progressively combine the separate modules into small segments rather than merging all of the units into one large component

Integration testing will be cross the modules. MM-SD-FICO for example.

TESING :(CONTD)

Objectives:

1>To check that all data exchanged across an interface agree with the data structure specifications

2>To confirm all the control flows 3>To check the data reliability 4>To check all the communication delays 5>To check the Operating system features like memory consumption

TESTING: (contd.)

C) SPT (STRESS PERFORMANCE TESTING) : Performance Test and Load / Stress Test determine the ability of the application to perform while under load. During Stress/Load testing the tester attempts to stress or load an aspect of the system to the point of failure - the goal being to determine weak points in the system architecture. The tester identifies peak load conditions at which the program will fail to handle required processing loads within required time spans. During Performance testing the tester designs test case scenarios to determine if the system meets the stated performance criteria (i.e. A Login request shall be responded to in 1 second or less under a typical daily load of 1000 requests per minute.). In both cases the tester is trying to determine the capacity of the system under a known set of conditions. The same set of tools and testing techniques can be applied for both types of capacity testing - only the goal of the test changes.

D) Regression testing : Regression testing is referred to a test which verifies that some new configuration doesn't adversely impact existing functionality. This will be done on each phase of testing.

Testing Strategies :

Unit Testing Plan (UTP) :

In the technical specification we have Unit Testing Plan section which looks like shown below.

Normal Functionality - test cases that ensure the workflow functions as it should. (e.g. updates fields correctly, processes all records).

Testing Strategies : (CONTD)

Test

Step

Step

Test

Expected

Actual

Executed

Remarks

Condition

Description

Data

Result

Result

By/Date

1.Test

1

Enter valid

 

An ALV

     

normal

selection

grid report

execution

conditions

of

of the

on the

material

report

selection

master

using valid

screen and

details

selection

execute

conditions

Testing Strategies : (CONTD)

Exception - special logic or exceptions (e.g. do not process Government Markets customers, only process pre-packs). exceptions are some specials conditions that restrict the execution.

Eg :

Test

TEST

Step

Test

Expected

Actual

Executed

Remar

Condition

Description

Data

Result

Result

By/Date

ks

               

Testing Strategies : (CONTD)

Error Handling - functionality in case of errors (e.g. Customer not found, Record already exists).

Eg.

Test

Step

Step

Test

Expected

Actual

Executed

Remarks

Condition

Description

Data

Result

Result

By/Date

Invalid

1

Enter

 

An error

     

‘Plant’

invalid

message

at the

‘Plant’

"The plant

selection

In selection

entered is

screen

condition

invalid" is

input

and execute

thrown

Testing Strategies : (CONTD)

The following should be tested in the UTP:

Defaults All calculations Check that database selects are returning the correct data Check return codes Screen flows are correct Screen information is correctly displayed Database updates/modifications are correct Standard header is used (if applicable) Sorts are correct Subtitles are correct Negative signs on numbers are in the right place Any rounding is occurring correctly Any truncation is occurring correctly If there is no data to be displayed, an appropriate message occurs Any error checks and/or validations performed by the program etc

Testing Strategies : (CONTD)

General tests while coding :

Whenever we write our code we keep on testing after certain steps in order to make or code more systematic.

For example if we have a simple object where we enter some inputs on the selection screen and depending on that a master material report is generated.

Testing Strategies : (CONTD)

First we check the validations. For this we go to the event at selection-screen and test the validations of each field individually. We test whether proper error messages are thrown on entering wrong inputs etc.

After that we check whether the internal tables are populated or not and depending on that proper message should be thrown. For this we go to the debugging mode and

inspect the internal tables.

Testing Strategies : (CONTD)

Testing Strategies : (CONTD)

TRANSPORT REQUEST :

Transports of changes by the CTS allow you to develop in one environment, test your development work in a test environment, and then, if the tests are successful, use it productively. This makes sure that productive operations are not placed at risk by faulty settings or program errors.

The CTS records all changes in change requests. The changes in change requests can be linked together logically, or can be completely independent of each other. Developers in a team can use a common request. You can create documentation for a change request, where you can describe your changes in more detail. This makes it easier to see which data was changed by which user, and to what purpose.

TRANSPORT REQUEST : (CONTD)

Customizing request: Under this request type we have the requests that are assigned to client-specific objects.

Workbench request: Under this request type we have the requests that are assigned to cross-client objects.

Transaction Codes

Transaction Code

Transaction Text

SE80

Object Navigator

SE38

ABAP Editor

SE11

ABAP Dictionary Maintenance

SE16

Data Browser

SM30

Call View Maintenance

SE93

Maintain Transaction Codes

SE37

ABAP Function Modules

SE10

Transport Organizer

AL11

Display SAP Directories

Transaction Codes (Contd.)

Transaction Code

Transaction Text

SE91

Message Maintenance

SM35

Batch Input Monitoring

SM37

Overview of job selection

SM12

Display and Delete Locks

SE18

Business Add-Ins: Definitions

SE19

Business Add-Ins: Implementations

SE24

Class Builder

SHDB

Batch Input Transaction Recorder

SQ01

SAP Query: Maintain queries