Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Copyright
IBM Corporation 2007
2013
IBM Global Business Services
Copyright
IBM Corporation 2007
2013
IBM Global Business Services
OVERVIEW
Delivery Class
Data Browser /Table view Maintenance
Technical Settings
Table Maintenance Generator
Data
Dictionary
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 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 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.)
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.)
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.
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 dont 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.
Changes are
recorded by individual
event routines, if
defined, or not at all.
Go to transaction se93 to
attach a T code to TMG
To create a
parameter T code we
have to choose the
Parameter
transaction
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.
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.
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?
i -2.147.483.648 to +2.147.483.647 0
n Any alphanumeric characters, however, valid values are only the "0" for every
digits 0 to 9 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
p decimal separator, up to 14 decimal places are permitted.
Depending on the field length len and the number of decimal 0
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.
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:
1.Type Declaration.
First Method Second Method
types: begin of ty_cepc, types: begin of ty_cepc,
bukrs type bukrs, bukrs type cepc-bukrs,
prctr type prctr, prctr type cepc-prctr,
datbi type datbi, datbi type cepc-datbi,
kokrs type kokrs, kokrs type cepc-kokrs,
end of ty_cepc. end of ty_cepc.
Selection-screen manipulation
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 dont have the full set of primary key then we use the SELECT UPTO 1 ROW clause
1) sign
2) option
3) low
4) high
Sign Meaning
I Include the values
O Exclude the values
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
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.
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.
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.
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.
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.
Now we want to collate these two internal tables into a final table t_final which looks like
the following.
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.)
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.
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.
*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.
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.
Note 2:
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.
In this case before the READ TABLE statement, t_vbpa should be first
sorted by vbeln and then by posnr as shown below.
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.
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
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.)
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.
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.
OR
Here You can add what ever you want to show in your documentation.
Debugging :
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)
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)
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)
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)
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)
Similarly we can load the debugger session that we have saved when we want.
PATH:
Debugger------->debugger session------->load PATH:
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:
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.
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.)
Testing Strategies :
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.
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.
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.
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