Matchcode concept

The Matchcode Concept

A matchcode is a utility that helps you to search for data records
stored in the system. Matchcodes are an efficient, user-friendly
aid to locating records for which you do not know the key.
Example: You are required to enter the matriculation number
(primary key) for a student in an input field, but only know the
students first name or surname. With this information, a
matchcode search allows you to quickly locate the student's
matriculation number.
Matchcode Components
You define a matchcode in the ABAP/4 Dictionary in two stages:
1. The relevant tables and fields are specified in
a matchcode object . A matchcode object describes the set
of all possible search paths for a search term.
2. You can then specify one or more matchcode IDs for a
matchcode object. A matchcode ID describes a specific
search path for a search term. In the matchcode ID you
determine which fields or combinations of fields you wish to
include in the search path.
Example: You can search for a student's matriculation number
using the student's first name, surname or address. The
matchcode you require in order to be able to do this would,
therefore, consist of the fields matriculation number, first name,
surname, and address and of the tables containing these fields.
You could then define specific access paths for this matchcode
object in the matchcode IDs. For example, ID 1 might describe
access via first name and surname, ID 2 access via address.
Matchcode Object

In a matchcode object you start by defining the area of the

database to be used to form the matchcode by specifying the
relevant tables and fields. A matchcode object is not stored
physically, but describes a comprehensive logical view on one or
more tables. You define the structure of this view by determining
which tables are to be used in the matchcode object and
specifying which foreign key relationships are to exist between
these tables.
When selecting the tables, you first need to choose a primary
table to which other tables can then be added. These other
tables are then linked to the primary table by means of foreign
keys. This link may be a transitive link. These additional tables are
called secondary tables.
Matchcode IDs
A matchcode object can have several matchcode IDs. The
matchcode IDs are derived from the matchcode object by means
of projection (field selection) and selection (specification of a
selection condition). Matchcode IDs for a particular matchcode
object are distinguished by a single character (letter or figure).
Consequently, up to 36 matchcode IDs (26 letters and 10 figures)
can be defined for each matchcode object. The figures 0 to 9 are
reserved for matchcode IDs created by customers.
2) Step-loops in Module Pool Programming
A) Step-loops in Module Pool Programming
Step-loops are actually the predecessors to Table Control concepts
and from programming point of view they are quite similar. Step
loops are objects for screen table display that are added to a
screen in the Screen Painter. They are preferred in cases of Radiofrequency applications where ALV displays or table controls pose a
hindrance with respect to small displays and navigational issues.
Fixed Step-loops

Incase of Fixed step-loops, the number of lines of records would

be fixed as when designed. You can increase the number of
records at runtime. Although the number of records can be
decreased as per programming logic if number of records in table
to be displayed are less than fixed number.

Variable Step-loops
In case of variable step-loops, at runtime we can increase the
number of repetitive blocks depending on the size of the screen.

3) SAP MEMORY and ABAP MEMORY?

abap memory is local memory,

sap memory is global memory

SAP Memory
SAP memory is a memory area to which all main sessions within a
SAPgui have access. You can use SAP memory either to pass data
from one program to another within a session, or to pass data
from one session to another. Application programs that use SAP
memory must do so using SPA/GPA parameters (also known as
SET/GET parameters). These parameters can be set either for a
particular user or for a particular program using the SET
PARAMETER statement. Other ABAP programs can then retrieve
the set parameters using the GET PARAMETER statement. The
most frequent use of SPA/GPA parameters is to fill input fields on
screens

ABAP/4 Memory

ABAP memory is a memory area that all ABAP programs within

the same internal session can access using the EXPORT and
IMPORT statements. Data within this area remains intact during a
whole sequence of program calls. To pass data
to a program which you are calling, the data needs to be placed in
ABAP memory before the call is made. The internal session of the
called program then replaces that of the calling program. The
program called can then read from the ABAP memory. If control is
then returned to the program which made the initial call, the
same process operates in reverse.
ABAP MEMORY AND SAP MEMORY
Skip to end of metadata

Added by R Sampath Kumar, last edited by R Sampath

Kumar on Sep 03, 2014
Go to start of metadata
ABAP MEMORY-It uses export and import parameters when an
active internal session
calls another internal session within a single main session .
SAP MEMORY- It uses set and get parameters to pass the data
from one main session to another main session.

SAP memory is a memory area to which all main sessions within a

SAPgui have access. You can use SAP memory either to pass data
from one program to another within a session, or to pass data
from one session to another. Application programs that use SAP
memory must do so using SPA/GPA parameters (also known as
SET/GET parameters). These parameters can be set either for a
particular user or for a particular program using the SET
PARAMETER statement. Other ABAP programs can then retrieve

the set parameters using the GET PARAMETER statement. The

most frequent use of SPA/GPA parameters is to fill input fields on
screens
ABAP memory is a memory area that all ABAP programs within
the same internal session can access using the EXPORT and
IMPORT statements. Data within this area remains intact during a
whole sequence of program calls. To pass data
to a program which you are calling, the data needs to be placed in
ABAP memory before the call is made. The internal session of the
called program then replaces that of the calling program. The
program called can then read from the ABAP memory. If control is
then returned to the program which made the initial call, the
same process operates in reverse.
External session: - when user logs on to R/3 system, the system
Creates a new terminal session called external session. E.g.
System Session.
Internal session: - created by calling a transaction (with CALL
TRANSACTION), a dialog module (with CALL DIALOG) or a report
(with SUBMIT or RETURN).
In general each user can open up to six R/3 windows in a single
SAPgui session. Each of these windows corresponds to a session
on the application server with its own area of shared memory.
The first application program that you start in a session opens an
internal session within the main session. The internal session has
a memory area that contains the ABAP program and its
associated data. When the program calls external routines
(methods, subroutines or function modules) their main program
and working data are also loaded into the memory area of the
internal session.
Only one internal session is ever active. If the active application
program calls a further application program, the system opens
another internal session. Here, there are two possible cases: If the
second program does not return control to the calling program
when it has finished running, the called program replaces the

calling program in the internal session. The contents of the

memory of the calling program are deleted. If the second program
does return control to the calling program when it has finished
running, the session of the called program is not deleted. Instead,
it becomes inactive, and its memory contents are placed on a
stack.

The memory area of each session contains an area called ABAP

memory. ABAP memory is available to all internal sessions. ABAP
programs can use the EXPORT and IMPORT statements to access
it. Data within this area remains intact during a whole sequence of
program calls. To pass data to a program which you are calling,
the data needs to be placed in ABAP memory before the call is
made. The internal session of the called program then replaces
that of the calling program. The program called can then read
from the ABAP memory. If control is then returned to the program
which made the initial call, the same process operates in reverse.

All ABAP programs can also access the SAP memory. This is a
memory area to which all sessions within a SAPgui have access.
You can use SAP memory either to pass data from one program to
another within a session, or to pass data from one session to
another. Application programs that use SAP memory must do so
using SPA/GPA parameters (also known as SET/GET parameters).
These parameters are often used to preassign values to input
fields. You can set them individually for users, or globally
according to the flow of an application program. SAP memory is
the only connection between the different sessions within a
SAPgui.

******************ABAP MEMORY - with export and import

parameters****************
REPORT YSP_0136.

data : name1(10) type c value 'aaaaaaaaaa'. export name1

to memory id 'MEM1'. SUBMIT YSP_0137 AND RETURN.
WRITE 'SSSSSSSS'.
********************************************************
REPORT YSP_0137

DATA : NAME2(10) TYPE C. IMPORT NAME1 TO NAME2 FROM

MEMORY ID 'MEM1'. WRITE NAME2.

***********ABAP MEMORY - with export and import

parameters****************
REPORT ZPGM1.
data : text1 type char20 value 'export and import'.

export text1
text2 from 'ex and im' to memory id 'MEM'.

SUBMIT ZPGM2 AND RETURN.

REPORT ZPGM2.
DATA : T1 TYPE CHAR20.
DATA : T2 TYPE CHAR20.
IMPORT TEXT1 TO T1 FROM MEMORY ID 'MEM'.
IMPORT TEXT2 TO T2 FROM MEMORY ID 'MEM'.

WRITE :/ T1.
WRITE :/ T2.

****************************OUTPUT **************
export and import
ex and im

************ABAP MEMORY - with export and import

parameters**************
data : t1 type char15 value 'ex and im'.

export t1 to memory id 'mem'.

t1 = 'xxxxxxxxxx'.
write :/ sy-subrc , t1.
import t1 from memory id 'mem'. " or free memory.
write :/ sy-subrc , t1.
t1 = 'xxxxxxxxxx'.
free memory id 'mem'.
import t1 from memory id 'mem'.
write :/ sy-subrc , t1.

*************output of program ****************

0 xxxxxxxxxx
0 ex and im
4 xxxxxxxxxx
***************ABAP MEMORY
parameters ****************

with

export

data : text(10) value '0123456789',

iden(3) value 'xyz'.

export text to memory id iden.

text = 'xxxxxxxxxx'.

import text from memory id iden.

write :/ sy-subrc, text.

free memory . " free memory id iden.

text = 'xxxxxxxxxx'.
import text from memory id iden.
write :/ sy-subrc, text.
******************SAP MEMORY - with set and get
parameters*******************

and

import

REPORT YSP_0138

DATA TEXT1(30) TYPE C VALUE 'SET AND GET PARAMETER'.

SET PARAMETER ID 'MEM' FIELD TEXT1.

WRITE : 'SET PARAMETER'.

*************************************************
REPORT YSP_0139

DATA TEXT2(30) TYPE C .

GET PARAMETER ID 'MEM' FIELD TEXT2.
WRITE : / TEXT2.
WRITE : 'GET PARAMETER'.

Q) How to declare select-option as a parameter?

A) YOU CAN
PARAMETERS

APPLY

SELECT-OPTIONS:VBELN
EXTENSION.

THIS
FOR

STATEMENT
VBAK-VBELN

FOR

ACTING

NO-INTERVELS

LIKE
NO

Q) WHAT IS THE DIFFERENCE BETWEEN THE T-CODES OF

CORRECTION AND TRANSPORT SYSTEMS SE09 SE01 SE10.
A) SE01 is the main screen of the Change and transport
Organizer. From here the administrator can acheive all tasks
related to transport requests - such as create, change, view logs,
display client/delivery transports, etc. SE09 and SE10 can also be

accessed from here. However, not all developers might be

granted access to this transaction.

SE09 is the workbench transport requests transaction - here the

developers can track changes to all ABAP workbench objects
(dictionary, reports, module pools, etc). This is a developerspecific transaction and mostly all developers have access to this
transaction.

SE10 is the customizing request display transaction - this displays

all the customizing requests in the system. Again, this could be
restricted to Business analysts if required, since they would be
doing most of the customizing changes in the system.

Interfaces, like classes, define a set of properties, methods, and

events. But unlike classes, interfaces do not provide
implementation. An interface represents a contract, and a class
that implements an interface must implement every aspect of
that interface exactly as it is defined.
You declare an interface by using the interface keyword

Example
interface IPerson
{
void Eat();

void Sleep();

int Weight
{
set;
get;
}
}

In order to use this interface, you must declare your class in the
same way that you declare a class inheriting from any other
object.

Example
public class Man:IPerson
{
int iWeight;

public Man()
{
}

public void Eat()

{
MessageBox.Show("Man:Eat");
}

public void Sleep()

{
MessageBox.Show("Man:Sleep");
}

public int Weight

{
set
{
iWeight = value;
}
get
{
return iWeight;
}

static void Main()

{
Man i = new Man();
i.Eat();
i.Sleep();
}

You get the following result when you run the above code.
Man:Eat
Man:Sleep

It is important to note here that an interface is very different from

a base class. An interface is implemented, not extended.
1.A class can implement multiple interfaces.
2.An interface cannot contain data declarations but you can
declare properties.
3.All method declarations in an interface are public.

4.There can be no implementation in an interface.

5.The class implementing the interface must provide
implementation code.
6.An interface can be derived from another interface

What is an Abstract Class?

Abstract Class is a special kind of class which cant be
instantiated. We can only instantiate the subclasses of the
Abstract class if they are not abstract. Abstract class should at
least contain one abstract method. Abstract methods are methods
without any implementation only a declaration. We can certainly
define the variables referencing to Abstract class and instantiate
with specific subclass at runtime.
Simple Abstract Class

*
CLASS zcl_base_functions DEFINITION ABSTRACT.
PUBLIC SECTION.
METHODS: set_my_name ABSTRACT IMPORTING iv_text TYPE
STRING .
METHODS: write_name.
PRIVATE SECTION.
DATA: my_name TYPE STRING.
ENDCLASS.
*

"zcl_base_functions DEFINITION

CLASS zcl_base_functions IMPLEMENTATION.

METHOD write_name.
ENDMETHOD.
ENDCLASS.

"write_name
"zcl_base_functions IMPLEMENTATION

What is an Interface?
An interface is not a class. It is an entity which cant have
implementation. An interface can only contain empty method
declaration and components. Interface components are always
public. We can later change the visibility of the components within
the implementing class using the ALIASES.
Simple Interface

INTERFACE zif_order.
METHODS: set_order_data IMPORTING iv_order_Data TYPE
STRING.
METHODS: create_order.
ENDINTERFACE.
*
CLASS zcl_sales_order DEFINITION.
PUBLIC SECTION.
INTERFACES: zif_order.
ENDCLASS.

Differences
Since both abstract class and interface are different entity, they
have few differences:
Multiple Inheritance:We can achieve multiple inheritance
using Interfaces. Since ABAP doesnt support more than one
Super class, we can have only one abstract class as Super
class.
New Functionality:If we add a new method in the
Interface, all the implementing classes have to implement
this method. If we dont implement the method, it would
result into Run-time error. For Abstract class, if we add a nonabstract method, its not required to redefine that in each
and every inherited class.
Default Behavior:We can have a default behavior of a nonabstract method in abstract class. We cant have any
implementation in Interface as it only contains the empty
stub.
Visibility:All interface components are PUBLIC by default.
For Abstract class, we can set the visibility of each
component.
Recommendations
Based on the above mentioned differences, we can come to this
recommendations:
If want to have multiple inheritance, you need to use
Interface. As we can have more than one interface in the
class definition, we can achieve multiple inheritance.
If wish to create multiple flavors of the object with some
default operations, you should consider creating abstract
class. As it provides you the flexibility to add the default
operations directly to base class and all the subclass would
get the new default operation.

 If you want to provide common, implemented functionality

among all implementations of your component, use an
abstract class. Abstract classes allow you to partially
implement your class, whereas interfaces contain no
implementation for any members.
Interface should be used when working for a wide range of
objects as interfaces only contain the stub, which enforces
no default behavior. Abstract class should be used for
classes which are closely related to each other.
We should use Interfaces for small functionalities which can
be clubbed together to derived the concrete business object.
Interfaces, in contrary to abstract class, gain interface
functionality no matter which hierachy tree they lie. So
interface become common point to hierarchies which cant
normally seat one next to another. Futhermore if they require
common implementation, a helper class can be utilized here.
Thanks to Marcin.
Let me know, if I have missed to have any point here.
Transparent Table : Exists with the same structure both in
dictionary as well as in database exactly with the same
data and fields.

Pooled Table : Pooled tables are logical tables that must

be assigned to a table pool when they are defined. Pooled
tables are used to store control data. Several pooled
tables can be cominied in a table pool. The data of these
pooled tables are then sorted in a common table in the
database.

Cluster Table : Cluster tables are logical tables that must

be assigned to a table cluster when they are defined.
Cluster tables can be used to strore control data. They can
also be used to store temporary data or texts, such as
documentation.

difference between Standard tables, Pooled tables and

Clusterd Tables
A transparent table is a table that stores data directly. You
can read these tables directly on the database from
outside SAP with for instance an SQL statement.

Transparent table is a one to one relation table i.e. when

you create one transparent table then exactly same table
will create in data base and if is basically used to store
transaction data.

A clustered and a pooled table cannot be read from

outside SAP because certain data are clustered and
pooled in one field.

One of the possible reasons is for instance that their

content can be variable in length and build up. Database
manipulations in Abap are limited as well.

But pool and cluster table is a many to one relationship

table. This means many pool table store in a database
table which is known as table pool.

All the pool table stored table in table pool does not need
to have any foreign key relationship but in the case of
cluster table it is must. And pool and cluster table is
basically use to store application data.

Table pool can contain 10 to 1000 small pool table which

has 10 to 100 records. But cluster table can contain very
big but few (1 to 10) cluster table.

For pool and cluster table you can create secondary index
and you can use select distinct, group for pool and cluster
table. You can use native SQL statement for pool and
cluster table.

A structure is a table without data. It is only filled by

program logic at the moment it is needed starting from
tables.

A view is a way of looking at the contents of tables. It only

contains the combination of the tables at the basis and
the way the data needs to be represented. You actually
call directly upon the underlying tables.