1 Application Link Enabling (ALE)
The ALE concept supports the construction and operation of distributed applications.
The basic principle is the guarantee of a distributed, yet fully integrated, R/3 System installation.
It incorporates the controlled exchange of business data messages whilst ensuring data consistency across loosely coupled R/3 Systems.
The integration of various applications is achieved by using synchronous and asynchronous communication, rather than by means of a central database.
ALE comprises three layers:
• the applications services,
• the distribution services,
• the communications services.
2 Transaction Data
Transaction data is data that results from daily business management processes. Examples of transaction data are purchase order data and accounting data.
3 CO-PA
Abbreviation for Controlling - Profitability Analysis.
4 EDI - Electronic Data Interchange
Electronic Data Interchange is the electronic exchange of structured data (e.g. commercial documents) that is not limited to a single company, but which may take place between business partners at home or abroad who can be using different hardware, software and communication services.
5 Filter Object
A specific instance of the filter object type to which an organizational unit has been assigned, for example, "Plant" ® "Plant 0001".
6 Filter Object Type
A filter object type is a selection criterion in the distribution reference model that specifies the criteria which determine whether a function type can be used several times in a distributed system.
7 Function
A specific instance of a function type in the customer model.
8 Function Type
A function type defines a self-contained process in an application. An example of this is the posting for a movement of goods in inventory management.
9 Function Type, Distributable
A collection of function types which may be grouped together because of the related use of the various function types, and which may be seen as being distinct from other function types.
10 IDoc
Abbreviation of intermediate document (IDoc type )
11 IDoc Type - Intermediate Document Type
An intermediate document type is the structure of the data container used for transporting data from a system to a target system. It is independent of any specific application data.
12 Logical System
A logical system is a system in which different applications are integrated and run using common data. In SAP terms, this means a client in a database.
13 Information Structures
The most important key figures are selected from the mass of data arising from operational applications and are stored in special statistics files known as information structures. These include information on the time period, the characteristics and the key figures. An information structure can be distributed.
14 Key Figures
Key figures represent information that is periodically gathered or evaluated for characteristics (for example, lead time, deviation from schedule, capacity utilization, order stocks, quantities and rejects).
15 Bulk Processing
Several IDocs may be grouped into a packet and processed in a single step. This is called bulk processing.
16 Characteristic
A characteristic is a piece of information that can be used to effect a division in a group of objects, for example, plant, work center, material).
17 Message Type
The messages exchanged between systems are of various message types. The message type depends on the data contained and the process involved. It determines the technical structure of the message, the IDoc type. For example, the ORDERS message type is used for purchase order messages.
18 Periods
Periods include days, weeks, months and accounting periods.
19 Item Category
An item category is a classification that distinguishes between various types of item in, for example, an order (e.g. cost-free items, standard items). The way that processing is controlled depends on the item category.
20 Serialization
If several IDocs are sent within a short period of time then "overtaking" can occur, so that later changes arrive sooner than changes that were actually made earlier. In order to avoid incorrect updates being made, a serialization mechanism must be used that can spot "overtaking" and report it.
21 SOP
Sales & Operations Planning.
22 Customer Distribution Model
The customer stores the exact distribution of functions across his various systems in the customer distribution model. The logical systems and message flows are specified here, possibly based on defined listings.
23 Distribution Reference Model
The reference model is included in the standard delivery from SAP. It specifies which functions can be distributed and how, and which data is exchanged between the fucntions. The customer uses the reference model as the basis for his customer distribution model .
24 Workflow
A workflow is defined as a sequence of processing steps (work item ). There may be branching points within this sequence.
A workflow has a container. This holds the parameters used in the processing steps.
In order to terminate the processing steps of a workflow, an event is triggered. The parameters are passed from the current step to the workflow container.
The workflow manager checks which processing step should be called next. For example, if an 'Idoc read' step is terminated and a parameter indicating an error is passed, a step will be started that initiates manual processing.
An error will also cause an event to be triggered If a function module has been called directly. However, in contrast to the situation with a workflow, it does not cause a workflow step to be terminated, but rather an error workflow is started.
25 Work Item
A work item represents the run-time environment for a standard task that is defined once in the system. A standard task contains a method that can be used for processing a specific object.
Sep 20, 2008
Sep 19, 2008
SAP LOCK CONCEPT
SAP LOCK CONCEPT:
If several users are competing to access the same resource or resources, you need to find a way of synchronizing the access in order to protect the consistency of your data.
Example: In a flight booking system, you would need to check whether seats were still free before making a reservation. You also need a guarantee that critical data (the number of free seats in this case) cannot be changed while you are working with the program.
Locks are a way of coordinating competing accesses to a resource. Each user requests a lock before accessing critical data.
It is important to release the lock as soon as possible, so as not to hinder other users unnecessarily.
Whenever you make direct changes to data on the database in a transaction, the database system sets corresponding locks.
The database management system (DBMS) physically locks the table entries that you want to change (INSERT; UPDATE, MODIFY), and those that you read from the database and intend to change (SELECT SINGLE FROM FOR UPDATE). Other users who want to access the locked record or records must wait until the physical lock has been released. In such a case, the ABAP program waits until the lock has been released again.
At the end of the database transaction, the database releases all of the locks that it has set during the transaction.
In the R/3 System, this means that each database lock is released when a new screen is displayed, since a change of screen triggers an implicit database commits.
To keep a lock set through a series of screens (from the dialog program to the update program), the R/3 System has a global lock table at the application server level, which you can use to set logical locks for table entries.
One application server contains this lock table and a special enqueue work process, which administers all requests for logical locks in the R/3 System. All logical lock requests of the R/3 System run using this work process.
You can also use logical locks to "lock" table entries that do not yet exist on the database (inserting new lines). You cannot do this with physical database locks.
For further information, see the ABAP Editor Keyword documentation for the term Locking.
Logical locks are generated when an entry is written in the lock table. You use function modules to do this.
You can only set a lock if the relevant table entry is not already locked.
The SAP transaction receives information on the success of a lock request from a return code sent via the EXCEPTION interface of the function module. In other words, the control is returned to the program using the function module. The ABAP program does not need to wait.
The SAP transaction can react appropriately by analyzing the return code.
Another user cannot gain access to work with the same table entries that are already locked.
Depending on the bundling technique in use for database updates), the program must delete the lock entries it generated using a lock module, or have them deleted indirectly (see unit Organizing Database Updates).
If the user terminates the program that generated the lock entries (usually a dialog program), the locks are released automatically (implicitly). You can do this by entering /n in the command field, or with the statements LEAVE PROGRAM, LEAVE TO TRANSACTION, and 'A' or 'X'
Messages.
When you call an ENQUEUE function module, the dialog program tries to generate a lock entry.
The export parameters identify the table entry (or entries) that you want to lock.
The program that generates the locks (usually dialog program) analyzes the return code for lock requests and reacts accordingly.
If the lock could not be set; you should normally output an error message.
At the end of the dialog program, you can use the corresponding DEQUEUE function module to delete the entries from the lock table.
DEQUEUE function modules have no exceptions. If you try to release an entry that is not locked, this has no effect.
If you want to release all of the locks that you have set, at the end of your dialog program, you can use the function module DEQUEUE_ALL.
The lock table contains the lock arguments for each table (for lock arguments, see the following slide).
To display the lock table, use transaction SM12.
The entries in the lock table are standard. Locks are always set using the values of the key fields in a table. These form the lock argument.
You pass the values for the lock argument to the lock modules via their interface (function module IMPORT parameters).
If you fail to set any of these parameters, the system interprets it generically, that is, the lock is set for all table lines that meet the criteria specified in the other parameters. The client parameter is an exception to this rule, where the default client SY-MANDT applies.
Lock entries must be assigned to a lock mode.
There are three different lock modes:
Mode 'E' for write locks: This is set if you want to write data to the database (change, create, or delete).
Mode 'S' for read locks: This is set if you want to ensure that the data, which you are reading from the database in your program, is not changed by other users while the program is running. You do not want to change the data itself in your program.
Mode 'X' for write locks: Like mode 'E', mode 'X' is used for writing data to the database. The technical difference between mode 'X' and mode 'E' is that locks of mode 'X' are not accumulated while a program is being executed. (For further details, see the following pages).
If someone tries to lock the same data record again with a second program (different user), the various lock modes take effect as follows:
Write locks ('E' or 'X') mean that any lock attempts from other users are refused, irrespective of the mode in which the lock is attempted.
If a data record is locked in mode 'S' (shared), further locks in mode 'S' may be set by other users.
Lock attempts in other lock modes ('E' or 'X') are refused.
If you want to try to lock a data record more than once while a program is running (for example using a function module that you call up, which sets locks itself), the lock system reacts in the following way:
Mode 'E' write locks are not refused. Instead, a cumulative counter is incremented. The same applies to read locks (mode 'S').
If a data record is locked in mode 'E', a lock request generates a second lock, which is marked as a read lock.
If a data record is locked in mode 'S' and no further read locks are set by other users, a lock attempt in mode 'E' is possible. This generates a second entry in the lock table (for mode 'E').
If a data record is locked in mode 'X', all further lock requests are refused.
If you want to ensure that you are reading up-to-date data in your program (with the intention of changing and returning this to the database), you should use the following procedure for lock requests and database accesses in your program:
First, lock the data that you want to edit.
Then read the current data from the database.
In the next step, process (change) the data in your program and write this to the database.
In the final step, release the locks that you set at the beginning.
This procedure ensures that your changes run fully with lock protection and that you only read data that has been changed consistently by other programs (provided that these also use the SAP lock concept and follow the procedure described here).
Lock modules are created for lock objects and not tables.
Lock objects are maintained in the dictionary. Customer lock objects must begin with "EY" or "EZ".
A lock object is a logical object composed of a list of tables that are linked by foreign key
Relationships. Lock modules are generated for these objects and enable common lock entries to be set for all tables contained in the lock object. This allows combinations of table entries to be locked.
Example: A lock object that contains the tables SFLIGHT and SBOOK enables a flight with its bookings to be locked.
The list of tables for a lock object consists of a primary table. Further table entries are referred to as secondary tables. Only tables with foreign key relationships to the primary table can be used as secondary tables.
With lock objects, you can assign different names for the parameters that describe the fields of the lock arguments for the lock modules. The names of the table fields (key fields of the tables) are proposed by the system.
You can specify the lock mode (a write lock 'E' or 'X' or a read lock 'S') for each table. These function as default values for the lock modules.
After you have assigned tables and default lock modes, lock objects must be generated.
When you activate a lock object, the system generates an ENQUEUE and a DEQUEUE function module.
These have the names ENQUEUE_ and DEQUEUE_ respectively.
If you want to ensure that you are reading current data in your program (with the intention of changing and returning this to the database), you should use the following procedure in your program for lock requests and database accesses:
1. Lock the data that you want to edit.
2. Read the current data from the database.
3. Process (change) the data in your program and write this to the database.
4. Release the locks that you set at the beginning.
This procedure ensures that your changes run fully with lock protection and that you only read data, which has been changed consistently by other programs (with the restriction that these are also using the SAP lock concept and following the procedure described).
If you change the order of the four steps to Read -> Lock -> Change -> Unlock, you run the risk that the data read by your program will not be up to date. Your program can read data before another user's program writes changes to the database. This means that a user of your program will make decisions for entries that are not based on up-to-date data from the database. For this reason, you should always follow the recommended procedure.
Requesting a lock from a program is a communication step with lock administration. The
Communication step requires a certain time interval. If your program sets locks for several objects, this interval occurs more than once.
By using so-called local lock containers, you can reduce these communication intervals with lock administration. To do so, collect the required lock requests of your program and send them together to lock administration.
The locks (delayed execution) can be collected when the lock modules are called. For this purpose, qualify the IMPORT parameter_collect with 'X'. The data transferred via the lock module interface is then registered in a list (lock container) as a lock request that needs to be executed.
The lock container can be terminated using the FLUSH_ENQUEUE function module and sent to lock administration.
When the lock orders of a lock container can be executed, the lock container is deleted.
If one of the locks in a container cannot be set, the function module FLUSH_ENQUEUE triggers the exception FOREIGN_LOCK. In this case, none of the registered lock requests is executed. The registered locks remain in the lock container.
You can delete the contents of an existing lock container with the function module
RESET_ENQUEUE.
The specified function modules have release status internally-released.
If several users are competing to access the same resource or resources, you need to find a way of synchronizing the access in order to protect the consistency of your data.
Example: In a flight booking system, you would need to check whether seats were still free before making a reservation. You also need a guarantee that critical data (the number of free seats in this case) cannot be changed while you are working with the program.
Locks are a way of coordinating competing accesses to a resource. Each user requests a lock before accessing critical data.
It is important to release the lock as soon as possible, so as not to hinder other users unnecessarily.
Whenever you make direct changes to data on the database in a transaction, the database system sets corresponding locks.
The database management system (DBMS) physically locks the table entries that you want to change (INSERT; UPDATE, MODIFY), and those that you read from the database and intend to change (SELECT SINGLE FROM FOR UPDATE). Other users who want to access the locked record or records must wait until the physical lock has been released. In such a case, the ABAP program waits until the lock has been released again.
At the end of the database transaction, the database releases all of the locks that it has set during the transaction.
In the R/3 System, this means that each database lock is released when a new screen is displayed, since a change of screen triggers an implicit database commits.
To keep a lock set through a series of screens (from the dialog program to the update program), the R/3 System has a global lock table at the application server level, which you can use to set logical locks for table entries.
One application server contains this lock table and a special enqueue work process, which administers all requests for logical locks in the R/3 System. All logical lock requests of the R/3 System run using this work process.
You can also use logical locks to "lock" table entries that do not yet exist on the database (inserting new lines). You cannot do this with physical database locks.
For further information, see the ABAP Editor Keyword documentation for the term Locking.
Logical locks are generated when an entry is written in the lock table. You use function modules to do this.
You can only set a lock if the relevant table entry is not already locked.
The SAP transaction receives information on the success of a lock request from a return code sent via the EXCEPTION interface of the function module. In other words, the control is returned to the program using the function module. The ABAP program does not need to wait.
The SAP transaction can react appropriately by analyzing the return code.
Another user cannot gain access to work with the same table entries that are already locked.
Depending on the bundling technique in use for database updates), the program must delete the lock entries it generated using a lock module, or have them deleted indirectly (see unit Organizing Database Updates).
If the user terminates the program that generated the lock entries (usually a dialog program), the locks are released automatically (implicitly). You can do this by entering /n in the command field, or with the statements LEAVE PROGRAM, LEAVE TO TRANSACTION, and 'A' or 'X'
Messages.
When you call an ENQUEUE function module, the dialog program tries to generate a lock entry.
The export parameters identify the table entry (or entries) that you want to lock.
The program that generates the locks (usually dialog program) analyzes the return code for lock requests and reacts accordingly.
If the lock could not be set; you should normally output an error message.
At the end of the dialog program, you can use the corresponding DEQUEUE function module to delete the entries from the lock table.
DEQUEUE function modules have no exceptions. If you try to release an entry that is not locked, this has no effect.
If you want to release all of the locks that you have set, at the end of your dialog program, you can use the function module DEQUEUE_ALL.
The lock table contains the lock arguments for each table (for lock arguments, see the following slide).
To display the lock table, use transaction SM12.
The entries in the lock table are standard. Locks are always set using the values of the key fields in a table. These form the lock argument.
You pass the values for the lock argument to the lock modules via their interface (function module IMPORT parameters).
If you fail to set any of these parameters, the system interprets it generically, that is, the lock is set for all table lines that meet the criteria specified in the other parameters. The client parameter is an exception to this rule, where the default client SY-MANDT applies.
Lock entries must be assigned to a lock mode.
There are three different lock modes:
Mode 'E' for write locks: This is set if you want to write data to the database (change, create, or delete).
Mode 'S' for read locks: This is set if you want to ensure that the data, which you are reading from the database in your program, is not changed by other users while the program is running. You do not want to change the data itself in your program.
Mode 'X' for write locks: Like mode 'E', mode 'X' is used for writing data to the database. The technical difference between mode 'X' and mode 'E' is that locks of mode 'X' are not accumulated while a program is being executed. (For further details, see the following pages).
If someone tries to lock the same data record again with a second program (different user), the various lock modes take effect as follows:
Write locks ('E' or 'X') mean that any lock attempts from other users are refused, irrespective of the mode in which the lock is attempted.
If a data record is locked in mode 'S' (shared), further locks in mode 'S' may be set by other users.
Lock attempts in other lock modes ('E' or 'X') are refused.
If you want to try to lock a data record more than once while a program is running (for example using a function module that you call up, which sets locks itself), the lock system reacts in the following way:
Mode 'E' write locks are not refused. Instead, a cumulative counter is incremented. The same applies to read locks (mode 'S').
If a data record is locked in mode 'E', a lock request generates a second lock, which is marked as a read lock.
If a data record is locked in mode 'S' and no further read locks are set by other users, a lock attempt in mode 'E' is possible. This generates a second entry in the lock table (for mode 'E').
If a data record is locked in mode 'X', all further lock requests are refused.
If you want to ensure that you are reading up-to-date data in your program (with the intention of changing and returning this to the database), you should use the following procedure for lock requests and database accesses in your program:
First, lock the data that you want to edit.
Then read the current data from the database.
In the next step, process (change) the data in your program and write this to the database.
In the final step, release the locks that you set at the beginning.
This procedure ensures that your changes run fully with lock protection and that you only read data that has been changed consistently by other programs (provided that these also use the SAP lock concept and follow the procedure described here).
Lock modules are created for lock objects and not tables.
Lock objects are maintained in the dictionary. Customer lock objects must begin with "EY" or "EZ".
A lock object is a logical object composed of a list of tables that are linked by foreign key
Relationships. Lock modules are generated for these objects and enable common lock entries to be set for all tables contained in the lock object. This allows combinations of table entries to be locked.
Example: A lock object that contains the tables SFLIGHT and SBOOK enables a flight with its bookings to be locked.
The list of tables for a lock object consists of a primary table. Further table entries are referred to as secondary tables. Only tables with foreign key relationships to the primary table can be used as secondary tables.
With lock objects, you can assign different names for the parameters that describe the fields of the lock arguments for the lock modules. The names of the table fields (key fields of the tables) are proposed by the system.
You can specify the lock mode (a write lock 'E' or 'X' or a read lock 'S') for each table. These function as default values for the lock modules.
After you have assigned tables and default lock modes, lock objects must be generated.
When you activate a lock object, the system generates an ENQUEUE and a DEQUEUE function module.
These have the names ENQUEUE_ and DEQUEUE_ respectively.
If you want to ensure that you are reading current data in your program (with the intention of changing and returning this to the database), you should use the following procedure in your program for lock requests and database accesses:
1. Lock the data that you want to edit.
2. Read the current data from the database.
3. Process (change) the data in your program and write this to the database.
4. Release the locks that you set at the beginning.
This procedure ensures that your changes run fully with lock protection and that you only read data, which has been changed consistently by other programs (with the restriction that these are also using the SAP lock concept and following the procedure described).
If you change the order of the four steps to Read -> Lock -> Change -> Unlock, you run the risk that the data read by your program will not be up to date. Your program can read data before another user's program writes changes to the database. This means that a user of your program will make decisions for entries that are not based on up-to-date data from the database. For this reason, you should always follow the recommended procedure.
Requesting a lock from a program is a communication step with lock administration. The
Communication step requires a certain time interval. If your program sets locks for several objects, this interval occurs more than once.
By using so-called local lock containers, you can reduce these communication intervals with lock administration. To do so, collect the required lock requests of your program and send them together to lock administration.
The locks (delayed execution) can be collected when the lock modules are called. For this purpose, qualify the IMPORT parameter_collect with 'X'. The data transferred via the lock module interface is then registered in a list (lock container) as a lock request that needs to be executed.
The lock container can be terminated using the FLUSH_ENQUEUE function module and sent to lock administration.
When the lock orders of a lock container can be executed, the lock container is deleted.
If one of the locks in a container cannot be set, the function module FLUSH_ENQUEUE triggers the exception FOREIGN_LOCK. In this case, none of the registered lock requests is executed. The registered locks remain in the lock container.
You can delete the contents of an existing lock container with the function module
RESET_ENQUEUE.
The specified function modules have release status internally-released.
ABAP List Viewer
ABAP List Viewer
The common features of report are column alignment, sorting, filtering, subtotals, totals etc. To implement these, a lot of coding and logic is to be put. To avoid that we can use a concept called ABAP List Viewer (ALV).
Using ALV, we can have three types of reports:
1. Simple Report
2. Block Report
3. Hierarchical Sequential Report
There are some function modules which will enable to produce the above reports without much effort.
All the definitions of internal tables, structures
and constants are declared in a type-pool called SLIS.
Simple Report
The important function modules are:
•Reuse_alv_list_display
•Reuse_alv_fieldcatalog_merge
•Reuse_alv_events_get
•Reuse_alv_commentary_write
•Reuse_alv_grid_display
A. REUSE_ALV_LIST_DISPLAY: This is the function module which prints the data.
The important parameters are:
1. Export:
a. I_callback_program : report id
b. I_callback_pf_status_set : routine where a user can set his own pf status or change the
functionality of the existing pf -status.
c. I_callback_user_command : routine where the function codes are handled.
d. I_structure name : name of the dictionary table
e. Is_Layout : structure to set the layout of the report
f. It_fieldcat : internal table with the list of all fields and their attributes which are to
be printed (this table can be populated automatically by the function
module REUSE_ALV_FIELDCATALOG_MERGE)
g. It_events : internal table with a list of all possible events of ALVand their
corresponding routine names.
2. Tables:
a. t_outtab : internal table with the data to be output
B. REUSE_ALV_FIELDCATALOG_MERGE:
This function module is used to populate a fieldcatalog which is essential to display the data in ALV. If the output data is from a single dictionary table and all the columns are selected, then we need not exclusively create the field catalog. Its enough to mention the table name as a parameter(I_structure_name) in the REUSE_ALV_LIST_DISPLAY. But in other cases we need to create it.
The important parameters are:
1. Export:
a. I_program_name : report id
b. I_internal_tabname : the internal output table
c. I_inclname : include or the report name where all the dynamic forms are handled.
2. Changing
ct_fieldcat : an internal table with the type SLIS_T_FIELDCAT_ALV which is declared in
the type pool SLIS.
C . REUSE_ALV_EVENTS_GET: Returns table of possible events for a a list type
1. Import:
Et_Events : The event table is returned with all possible CALLBACK events for the
specified list type (column ‘NAME’). For events to be processed by the
callback, their ‘FORM’ field must be filled. If the field is initialized, the event
is ignored. The entry can be read from the event table, the field ‘FORM’ filled
and the entry modified using constants from the type pool SLIS.
2. Export:
I_list_type:
0 = simple list
1 = hierarchical-sequential list
2 = simple block list
3 = hierarchical-sequential block list
D. REUSE_ALV_COMMENTARY_WRITE : This is used in the Top-of-page event to print the headings and other comments for the list.
1. It_list_commentary : Internal table with the headings of the type slis_t_listheader.
This internal table has three fields:
Typ : ‘H’ - header, ‘S’ - selection, ‘A’ - action
Key : only when typ is ‘S’.
Info : the text to be printed
E. REUSE_ALV_GRID_DISPLAY: A new function in 4.6 version, to display the results in grid rather than as a list.
Parameters : same as reuse_alv_list_display
HIERARCHICAL REPORTS
A. REUSE_ALV_HIERSEQ_LIST_DISPLAY
1. Export:
a. I_CALLBACK_PROGRAM
b. I_CALLBACK_PF_STATUS_SET
c. I_CALLBACK_USER_COMMAND
d. IS_LAYOUT
e. IT_FIELDCAT
f. IT_EVENTS
g. I_TABNAME_HEADER : Name of the internal table in the program containing the output data of the
highest hierarchy level.
h. I_TABNAME_ITEM : Name of the internal table in the program containing the output data of the
lowest hierarchy level.
i. IS_KEYINFO : This structure contains the header and item table field names which link the two tables
(shared key).
2. Tables
a. T_OUTTAB_HEADER : Header table with data to be output
b. T_OUTTAB_ITEM : Name of the internal table in the program containing the output data of the
lowest hierarchy level.
BLOCK REPORT
This is used to display multiple lists continuously.
The important functions used in this report are:
A. REUSE_ALV_BLOCK_LIST_INIT
B. REUSE_ALV_BLOCK_LIST_APPEND
C. REUSE_ALV_BLOCK_LIST_DISPLAY
D. REUSE_ALV_BLOCK_HS_LIST_APPEND
A. REUSE_ALV_BLOCK_LIST_INIT
Parameters:
a. I_CALLBACK_PROGRAM
b. I_CALLBACK_PF_STATUS_SET
c. I_CALLBACK_USER_COMMAND
This function module is used to set the default GUI status etc.
B. REUSE_ALV_BLOCK_LIST_APPEND
Export :
a. IS_LAYOUT : layout settings for block
b. IT_FIELDCAT : field catalog
c. I_TABNAME : Internal table name of the output data
d. IT_EVENTS : internal table name with all possible events
Tables :
a. T_OUTTAB : internal table with output data.
This function module adds the data to the block.
INTERNAL TABLES IN SLIS
Slis_t_fieldcat_alv :
This internal table contains the field attributes. This internal table can be populated automatically by using ‘REUSE_ALV_FIELDCATALOG_MERGE’.
Important Attributes:
a. col_pos : position of the column
b. fieldname : internal fieldname
c. tabname : internal table name
d. ref_fieldname : fieldname (dictionary)
e. ref_tabname : table (dictionary)
f. key(1) : column with key-color
g. icon(1) : icon
h. hotspot(1) : hotspot
i. Symbol(1) : symbol
j. Checkbox(1) : checkbox
k. just(1) : (R)ight (L)eft (C)ent
l. do_sum(1) : sum up
m. no_out(1) : (O)blig. (X)no out
n. outputlen : output length
o. seltext-l : long key word
p. seltext_m : middle key word
q. seltext_s : short key word
r. reptext_ddic : heading(ddic)
s. ddictxt(1) : (S)hort (M)iddle (L)ong
t. datatype : datatype
SLIS_T_EVENT :
Internal table for storing all the possible events of the ALV. This can be populated by the function module Reuse_alv_events_get
The columns are :
name : name of the event
form : name of the routine
SYNTAXES FOR THE ROUTINES
I_CALLBACK_PF_STATUS_SET
Syntax :
FORM set_pf_status USING rt_extab TYPE slis_t_extab
The table RT_EXTAB contains the function codes which are hidden in the standard interface.
I_CALLBACK_USER_COMMAND
Syntax :
FORM user_command USING r_ucomm LIKE sy-ucomm
rs_selfield TYPE slis_selfield.
The parameter r_ucomm contains the function code.
The structure rs_selfield has the details about the current cursor position.
The common features of report are column alignment, sorting, filtering, subtotals, totals etc. To implement these, a lot of coding and logic is to be put. To avoid that we can use a concept called ABAP List Viewer (ALV).
Using ALV, we can have three types of reports:
1. Simple Report
2. Block Report
3. Hierarchical Sequential Report
There are some function modules which will enable to produce the above reports without much effort.
All the definitions of internal tables, structures
and constants are declared in a type-pool called SLIS.
Simple Report
The important function modules are:
•Reuse_alv_list_display
•Reuse_alv_fieldcatalog_merge
•Reuse_alv_events_get
•Reuse_alv_commentary_write
•Reuse_alv_grid_display
A. REUSE_ALV_LIST_DISPLAY: This is the function module which prints the data.
The important parameters are:
1. Export:
a. I_callback_program : report id
b. I_callback_pf_status_set : routine where a user can set his own pf status or change the
functionality of the existing pf -status.
c. I_callback_user_command : routine where the function codes are handled.
d. I_structure name : name of the dictionary table
e. Is_Layout : structure to set the layout of the report
f. It_fieldcat : internal table with the list of all fields and their attributes which are to
be printed (this table can be populated automatically by the function
module REUSE_ALV_FIELDCATALOG_MERGE)
g. It_events : internal table with a list of all possible events of ALVand their
corresponding routine names.
2. Tables:
a. t_outtab : internal table with the data to be output
B. REUSE_ALV_FIELDCATALOG_MERGE:
This function module is used to populate a fieldcatalog which is essential to display the data in ALV. If the output data is from a single dictionary table and all the columns are selected, then we need not exclusively create the field catalog. Its enough to mention the table name as a parameter(I_structure_name) in the REUSE_ALV_LIST_DISPLAY. But in other cases we need to create it.
The important parameters are:
1. Export:
a. I_program_name : report id
b. I_internal_tabname : the internal output table
c. I_inclname : include or the report name where all the dynamic forms are handled.
2. Changing
ct_fieldcat : an internal table with the type SLIS_T_FIELDCAT_ALV which is declared in
the type pool SLIS.
C . REUSE_ALV_EVENTS_GET: Returns table of possible events for a a list type
1. Import:
Et_Events : The event table is returned with all possible CALLBACK events for the
specified list type (column ‘NAME’). For events to be processed by the
callback, their ‘FORM’ field must be filled. If the field is initialized, the event
is ignored. The entry can be read from the event table, the field ‘FORM’ filled
and the entry modified using constants from the type pool SLIS.
2. Export:
I_list_type:
0 = simple list
1 = hierarchical-sequential list
2 = simple block list
3 = hierarchical-sequential block list
D. REUSE_ALV_COMMENTARY_WRITE : This is used in the Top-of-page event to print the headings and other comments for the list.
1. It_list_commentary : Internal table with the headings of the type slis_t_listheader.
This internal table has three fields:
Typ : ‘H’ - header, ‘S’ - selection, ‘A’ - action
Key : only when typ is ‘S’.
Info : the text to be printed
E. REUSE_ALV_GRID_DISPLAY: A new function in 4.6 version, to display the results in grid rather than as a list.
Parameters : same as reuse_alv_list_display
HIERARCHICAL REPORTS
A. REUSE_ALV_HIERSEQ_LIST_DISPLAY
1. Export:
a. I_CALLBACK_PROGRAM
b. I_CALLBACK_PF_STATUS_SET
c. I_CALLBACK_USER_COMMAND
d. IS_LAYOUT
e. IT_FIELDCAT
f. IT_EVENTS
g. I_TABNAME_HEADER : Name of the internal table in the program containing the output data of the
highest hierarchy level.
h. I_TABNAME_ITEM : Name of the internal table in the program containing the output data of the
lowest hierarchy level.
i. IS_KEYINFO : This structure contains the header and item table field names which link the two tables
(shared key).
2. Tables
a. T_OUTTAB_HEADER : Header table with data to be output
b. T_OUTTAB_ITEM : Name of the internal table in the program containing the output data of the
lowest hierarchy level.
BLOCK REPORT
This is used to display multiple lists continuously.
The important functions used in this report are:
A. REUSE_ALV_BLOCK_LIST_INIT
B. REUSE_ALV_BLOCK_LIST_APPEND
C. REUSE_ALV_BLOCK_LIST_DISPLAY
D. REUSE_ALV_BLOCK_HS_LIST_APPEND
A. REUSE_ALV_BLOCK_LIST_INIT
Parameters:
a. I_CALLBACK_PROGRAM
b. I_CALLBACK_PF_STATUS_SET
c. I_CALLBACK_USER_COMMAND
This function module is used to set the default GUI status etc.
B. REUSE_ALV_BLOCK_LIST_APPEND
Export :
a. IS_LAYOUT : layout settings for block
b. IT_FIELDCAT : field catalog
c. I_TABNAME : Internal table name of the output data
d. IT_EVENTS : internal table name with all possible events
Tables :
a. T_OUTTAB : internal table with output data.
This function module adds the data to the block.
INTERNAL TABLES IN SLIS
Slis_t_fieldcat_alv :
This internal table contains the field attributes. This internal table can be populated automatically by using ‘REUSE_ALV_FIELDCATALOG_MERGE’.
Important Attributes:
a. col_pos : position of the column
b. fieldname : internal fieldname
c. tabname : internal table name
d. ref_fieldname : fieldname (dictionary)
e. ref_tabname : table (dictionary)
f. key(1) : column with key-color
g. icon(1) : icon
h. hotspot(1) : hotspot
i. Symbol(1) : symbol
j. Checkbox(1) : checkbox
k. just(1) : (R)ight (L)eft (C)ent
l. do_sum(1) : sum up
m. no_out(1) : (O)blig. (X)no out
n. outputlen : output length
o. seltext-l : long key word
p. seltext_m : middle key word
q. seltext_s : short key word
r. reptext_ddic : heading(ddic)
s. ddictxt(1) : (S)hort (M)iddle (L)ong
t. datatype : datatype
SLIS_T_EVENT :
Internal table for storing all the possible events of the ALV. This can be populated by the function module Reuse_alv_events_get
The columns are :
name : name of the event
form : name of the routine
SYNTAXES FOR THE ROUTINES
I_CALLBACK_PF_STATUS_SET
Syntax :
FORM set_pf_status USING rt_extab TYPE slis_t_extab
The table RT_EXTAB contains the function codes which are hidden in the standard interface.
I_CALLBACK_USER_COMMAND
Syntax :
FORM user_command USING r_ucomm LIKE sy-ucomm
rs_selfield TYPE slis_selfield.
The parameter r_ucomm contains the function code.
The structure rs_selfield has the details about the current cursor position.
Aug 28, 2008
Implementation Ques..
1. What are the responsibilities of a functional consultant in an implementation project?
a) Responsibilities in implementation project
- Preparing the functional specification documents.
- Review and approval of functional specifications.
- Designing a road map and setting approval from client.
- Changing existing configuration whenever needed.
- Setting up configuration for new enhancements.
- Handling basic issues of MM module.
b) Responsibilities in support project
- Handling customization, configuration, and enhancement related issues
- Handling tickets on Day to Day basis
- Monitoring S&D reports on daily basis required by clients
- Preparing functional specification documents
- Preparing end user training Documents
2. What are the responsibilities of a technical consultant in an implementation project?
Preparation of technical specifications, getting approvals from functional consultant and PM, assistance to functional consultant.
3.What is ERP and SAP? and why implementing SAP in an organization? Explain the special features of SAP over other ERPs?
SAP is an ERP package. SAP can be fit it any language. It is used to get exact data with a fraction of section which will be use fully for management to take correct decision in a short span of time. Using of sap means there is no need to maintain the
middle management in the organization because the CEO of the company is able to direct the executives directly with the system. SAP is able to integrate all functional organizational units together and retrieve exact data needed by management. Therefore, investing on middle management will become less. and the user will be able to access instance reports using the logistic information systems in SAP.
4.Explain the business flow of an implementation project?
- Project preparation
- Business blue prints
- Fit gap analysis
- Realization
- Go-live
- Support
5. Explain briefly about your role in current/previous project? (If you have one)
6. Explain your functional experience prior to SAP?
7. Can you explain the modern technologies in SAP? Do you use this in your current project?
8. Explain the terms "AS IS" and "FIT GAP ANALYSIS"?
Business blue print stage is called AS-IS process. Fit gap means, before implementing the SAP all the business data is in the form of documents, we cannot keep this data as is in the SAP. There should be a gap. So by filling this gap, we make configuration with the help of these documents. This is called as fit gap analysis. In this stage, we should analysis the gap between as is and is as process.
9. What are the responsibilities of "CORE TEAM" and "FUNCTIONAL TEAM" in an implementation?
Core Team are the power users who are selected for the SAP implementation. The Functional Team gather the initial implementation requirement from these core team users who will be the bridge between the SAP Functional Team and their department users with the expert work knowledge.
a) Responsibilities in implementation project
- Preparing the functional specification documents.
- Review and approval of functional specifications.
- Designing a road map and setting approval from client.
- Changing existing configuration whenever needed.
- Setting up configuration for new enhancements.
- Handling basic issues of MM module.
b) Responsibilities in support project
- Handling customization, configuration, and enhancement related issues
- Handling tickets on Day to Day basis
- Monitoring S&D reports on daily basis required by clients
- Preparing functional specification documents
- Preparing end user training Documents
2. What are the responsibilities of a technical consultant in an implementation project?
Preparation of technical specifications, getting approvals from functional consultant and PM, assistance to functional consultant.
3.What is ERP and SAP? and why implementing SAP in an organization? Explain the special features of SAP over other ERPs?
SAP is an ERP package. SAP can be fit it any language. It is used to get exact data with a fraction of section which will be use fully for management to take correct decision in a short span of time. Using of sap means there is no need to maintain the
middle management in the organization because the CEO of the company is able to direct the executives directly with the system. SAP is able to integrate all functional organizational units together and retrieve exact data needed by management. Therefore, investing on middle management will become less. and the user will be able to access instance reports using the logistic information systems in SAP.
4.Explain the business flow of an implementation project?
- Project preparation
- Business blue prints
- Fit gap analysis
- Realization
- Go-live
- Support
5. Explain briefly about your role in current/previous project? (If you have one)
6. Explain your functional experience prior to SAP?
7. Can you explain the modern technologies in SAP? Do you use this in your current project?
8. Explain the terms "AS IS" and "FIT GAP ANALYSIS"?
Business blue print stage is called AS-IS process. Fit gap means, before implementing the SAP all the business data is in the form of documents, we cannot keep this data as is in the SAP. There should be a gap. So by filling this gap, we make configuration with the help of these documents. This is called as fit gap analysis. In this stage, we should analysis the gap between as is and is as process.
9. What are the responsibilities of "CORE TEAM" and "FUNCTIONAL TEAM" in an implementation?
Core Team are the power users who are selected for the SAP implementation. The Functional Team gather the initial implementation requirement from these core team users who will be the bridge between the SAP Functional Team and their department users with the expert work knowledge.
Aug 12, 2008
Idoc - basics
SAP IDOC
Basically an IDOC is formed of segments, and comprises of IDOC Type and IDOC Data. IDOC types defines the structure and format of the data being exchanged.
Typically an IDOC will have the following
• Control Record
• Data Records
• Status Records
Control Record:
Will have all the following.
• IDOC number
• IDOC TYPE
• Sender and Receiver Information
• Message Type
Please note that there is only one control record per IDOC and the structure of IDOC control record is the same for all IDOCs.
Data Record:
This basically contains the data, the header data and the line item data for a particular IDOC for example Sales Order or Purchase Order. These are multiple records.
Status Record:
This represents the different status the IDOC goes through. And a status record will have multiple statuses. A status code, Date and Time are assigned.
Basically an IDOC is formed of segments, and comprises of IDOC Type and IDOC Data. IDOC types defines the structure and format of the data being exchanged.
Typically an IDOC will have the following
• Control Record
• Data Records
• Status Records
Control Record:
Will have all the following.
• IDOC number
• IDOC TYPE
• Sender and Receiver Information
• Message Type
Please note that there is only one control record per IDOC and the structure of IDOC control record is the same for all IDOCs.
Data Record:
This basically contains the data, the header data and the line item data for a particular IDOC for example Sales Order or Purchase Order. These are multiple records.
Status Record:
This represents the different status the IDOC goes through. And a status record will have multiple statuses. A status code, Date and Time are assigned.
Aug 11, 2008
Modularization FAQ
1. Does every ABAP/4 have a modular structure?
Yes.
2. What is Modularization and its benefits?
If the program contains the same or similar blocks of statements or it is required to process the same function several times, we can avoid redundancy by using modularization techniques. By modularizing the ABAP/4 programs we make them easy to read and improve their structure. Modularized programs are also easier to maintain and to update.
3. Name the ABAP/4 Modularization techniques.
· Source code module.
· Subroutines.
· Functions.
4. How can we create callable modules of program code within one ABAP/4 program?
· By defining Macros.
· By creating include programs in the library.
5. M is the attribute type of the module program.
6. Is it possible to pass data to and from include programs explicitly?
No. If it is required to pass data to and from modules it is required to use subroutines or function modules.
7. What are subroutines?
Subroutines are program modules, which can be called from other ABAP/4 programs or within the same program.
8. What are the types of Subroutines?
· Internal Subroutines: The source code of the internal subroutines will be in the same ABAP/4 program as the calling procedure (internal call).
· External Subroutines: The source code of the external subroutines will be in an ABAP/4 program other than the calling procedure.
9. It is not possible to create an ABAP/4 program, which contains only Subroutines (T/F).
False.
10. A subroutine can contain nested form and endform blocks. (T/F)
False.
11. Data can be passed between calling programs and the subroutines using Parameters.
12. What are the different types of parameters?
Formal Parameters: Parameters, which are defined during the definition of subroutine with the FORM statement.
Actual Parameters: Parameters which are specified during the call of a subroutine with the PERFORM statement.
13. How can one distinguish between different kinds of parameters?
· Input parameters are used to pass data to subroutines.
· Output parameters are used to pass data from subroutines.
14. What are the different methods of passing data?
· Calling by reference: During a subroutine call, only the address of the actual parameter is transferred to the formal parameters. The formal parameter has no memory of its own, and we work with the field of the calling program within the subroutine. If we change the formal parameter, the field contents in the calling program also changes.
· Calling by value: During a subroutine call, the formal parameters are created as copies of the actual parameters. The formal parameters have memory of their own. Changes to the formal parameters have no effect on the actual parameters.
· Calling by value and result: During a subroutine call, the formal parameters are created as copies of the actual parameters. The formal parameters have their own memory space. Changes to the formal parameters are copied to the actual parameters at the end of the subroutine.
15. The method by which internal tables are passed is By Reference.
16. How can an internal table with Header line and one without header line be distinguished when passed to a subroutine?
Itab [] is used in the form and endform if the internal table is passed with a header line.
17. What should be declared explicitly in the corresponding ABAP/4 Statements to access internal tables without header lines & why?
Work Area. This is required as the Work Area is the interface for transferring data to and from the table.
18. A subroutine can be terminated unconditionally using EXIT. (T/F)
True.
19. A subroutine can be terminated upon a condition using CHECK Statement.
20. Function Modules are also external Subroutines. (T/F).
True.
21. What is the difference between the function module and a normal ABAP/4 subroutine?
In contrast to normal subroutines function modules have uniquely defined interface. Declaring data as common parts is not possible for function modules. Function modules are stored in a central library.
22. What is a function group?
A function group is a collection of logically related modules that share global data with each other. All the modules in the group are included in the same main program. When an ABAP/4 program contains a CALL FUNCTION statement, the system loads the entire function group in with the program code at runtime. Every function module belongs to a function group.
23. What is the disadvantage of a call by reference?
During a call by reference damage or loss of data is not restricted to the subroutine, but will instantly lead to changes to the original data objects.
24. A function module can be called from a transaction screen outside an ABAP/4 program. (T/F).
True.
25. What is an update task?
It is an SAP provided procedure for updating a database.
26. What happens if a function module runs in an update task?
The system performs the module processing asynchronously. Instead of carrying out the call immediately, the system waits until the next database update is triggered with the ‘COMMIT WORK’ command.
27. When a function module is activated syntax checking is performed automatically. (Y/N)
True.
28. What is the use of the RAISING exception?
The raising exception determines whether the calling program will handle the exception itself or leave the exception to the system.
29. What is the difference between internal tables and extract datasets?
· The lines of an internal table always have the same structure. By using extract datasets, you can handle groups of data with different structure and get statistical figures from the grouped data.
· You have to define the structure of the internal table at the beginning. You need not define the structure of the extract dataset.
· In contrast to internal tables, the system partly compresses exact datasets when storing them. This reduces the storage space required.
· Internal tables require special work area for interface whereas extract datasets do not need a special work area for interface.
30.It is possible to assign a local data object defined in a subroutine or function module to a field group. (T/F).
False.
31. What is the difference between field-group header and other field groups?
The header field group is a special field group for the sort criteria. The system automatically prefixes any other field groups with the header field group.
33. Can a filed occur in several field groups.
Yes. But it leads to unnecessary data redundancy.
34. When sorting the extract dataset the fields used as default sort key lie in the Header field group.
35. What does the insert statement in extract datasets do?
It defines the fields of a field group.
36.What does the extract statement do in extract datasets?
The data is written to virtual memory by extract commands.
37. A field-groups statement or an insert statement reverses storage space and transfers values. (T/F).
False.
38. While using extract datasets it is required to have a special workarea for interface (T/F)
False.
39. The LOOP-ENDLOOP on extract datasets can be used without any kind of errors (T/F)
False. It causes runtime errors.
40. The Maximum no of key fields that can be used in a header is 50.
41. While sorting field groups we cannot use more than one key field (T/F).
False.
42. While sorting, if the main storage available is not enough, the system writes data to an external help file. The SAP profile parameter, which determines this help file, is DIR_SORTTMP.
43. The extract statements in field groups can be used before or after processing the sort statements. (T/F)
FALSE.
Yes.
2. What is Modularization and its benefits?
If the program contains the same or similar blocks of statements or it is required to process the same function several times, we can avoid redundancy by using modularization techniques. By modularizing the ABAP/4 programs we make them easy to read and improve their structure. Modularized programs are also easier to maintain and to update.
3. Name the ABAP/4 Modularization techniques.
· Source code module.
· Subroutines.
· Functions.
4. How can we create callable modules of program code within one ABAP/4 program?
· By defining Macros.
· By creating include programs in the library.
5. M is the attribute type of the module program.
6. Is it possible to pass data to and from include programs explicitly?
No. If it is required to pass data to and from modules it is required to use subroutines or function modules.
7. What are subroutines?
Subroutines are program modules, which can be called from other ABAP/4 programs or within the same program.
8. What are the types of Subroutines?
· Internal Subroutines: The source code of the internal subroutines will be in the same ABAP/4 program as the calling procedure (internal call).
· External Subroutines: The source code of the external subroutines will be in an ABAP/4 program other than the calling procedure.
9. It is not possible to create an ABAP/4 program, which contains only Subroutines (T/F).
False.
10. A subroutine can contain nested form and endform blocks. (T/F)
False.
11. Data can be passed between calling programs and the subroutines using Parameters.
12. What are the different types of parameters?
Formal Parameters: Parameters, which are defined during the definition of subroutine with the FORM statement.
Actual Parameters: Parameters which are specified during the call of a subroutine with the PERFORM statement.
13. How can one distinguish between different kinds of parameters?
· Input parameters are used to pass data to subroutines.
· Output parameters are used to pass data from subroutines.
14. What are the different methods of passing data?
· Calling by reference: During a subroutine call, only the address of the actual parameter is transferred to the formal parameters. The formal parameter has no memory of its own, and we work with the field of the calling program within the subroutine. If we change the formal parameter, the field contents in the calling program also changes.
· Calling by value: During a subroutine call, the formal parameters are created as copies of the actual parameters. The formal parameters have memory of their own. Changes to the formal parameters have no effect on the actual parameters.
· Calling by value and result: During a subroutine call, the formal parameters are created as copies of the actual parameters. The formal parameters have their own memory space. Changes to the formal parameters are copied to the actual parameters at the end of the subroutine.
15. The method by which internal tables are passed is By Reference.
16. How can an internal table with Header line and one without header line be distinguished when passed to a subroutine?
Itab [] is used in the form and endform if the internal table is passed with a header line.
17. What should be declared explicitly in the corresponding ABAP/4 Statements to access internal tables without header lines & why?
Work Area. This is required as the Work Area is the interface for transferring data to and from the table.
18. A subroutine can be terminated unconditionally using EXIT. (T/F)
True.
19. A subroutine can be terminated upon a condition using CHECK Statement.
20. Function Modules are also external Subroutines. (T/F).
True.
21. What is the difference between the function module and a normal ABAP/4 subroutine?
In contrast to normal subroutines function modules have uniquely defined interface. Declaring data as common parts is not possible for function modules. Function modules are stored in a central library.
22. What is a function group?
A function group is a collection of logically related modules that share global data with each other. All the modules in the group are included in the same main program. When an ABAP/4 program contains a CALL FUNCTION statement, the system loads the entire function group in with the program code at runtime. Every function module belongs to a function group.
23. What is the disadvantage of a call by reference?
During a call by reference damage or loss of data is not restricted to the subroutine, but will instantly lead to changes to the original data objects.
24. A function module can be called from a transaction screen outside an ABAP/4 program. (T/F).
True.
25. What is an update task?
It is an SAP provided procedure for updating a database.
26. What happens if a function module runs in an update task?
The system performs the module processing asynchronously. Instead of carrying out the call immediately, the system waits until the next database update is triggered with the ‘COMMIT WORK’ command.
27. When a function module is activated syntax checking is performed automatically. (Y/N)
True.
28. What is the use of the RAISING exception?
The raising exception determines whether the calling program will handle the exception itself or leave the exception to the system.
29. What is the difference between internal tables and extract datasets?
· The lines of an internal table always have the same structure. By using extract datasets, you can handle groups of data with different structure and get statistical figures from the grouped data.
· You have to define the structure of the internal table at the beginning. You need not define the structure of the extract dataset.
· In contrast to internal tables, the system partly compresses exact datasets when storing them. This reduces the storage space required.
· Internal tables require special work area for interface whereas extract datasets do not need a special work area for interface.
30.It is possible to assign a local data object defined in a subroutine or function module to a field group. (T/F).
False.
31. What is the difference between field-group header and other field groups?
The header field group is a special field group for the sort criteria. The system automatically prefixes any other field groups with the header field group.
33. Can a filed occur in several field groups.
Yes. But it leads to unnecessary data redundancy.
34. When sorting the extract dataset the fields used as default sort key lie in the Header field group.
35. What does the insert statement in extract datasets do?
It defines the fields of a field group.
36.What does the extract statement do in extract datasets?
The data is written to virtual memory by extract commands.
37. A field-groups statement or an insert statement reverses storage space and transfers values. (T/F).
False.
38. While using extract datasets it is required to have a special workarea for interface (T/F)
False.
39. The LOOP-ENDLOOP on extract datasets can be used without any kind of errors (T/F)
False. It causes runtime errors.
40. The Maximum no of key fields that can be used in a header is 50.
41. While sorting field groups we cannot use more than one key field (T/F).
False.
42. While sorting, if the main storage available is not enough, the system writes data to an external help file. The SAP profile parameter, which determines this help file, is DIR_SORTTMP.
43. The extract statements in field groups can be used before or after processing the sort statements. (T/F)
FALSE.
BDC Faq..
1. What is full form of BDC Session?
Batch Data Communication Session.
2. What are the steps in a BDC session?
The first step in a BDC session is to identify the screens of the transaction that the program will process. Next step is to write a program to build the BDC table that will be used to submit the data to SAP. The final step is to submit the BDC table to the system in the batch mode or as a single transaction by the CALL TRANSACTION command.
3. How do you find the information on the current screen?
The information on the current screen can be found by SYSTEM à STATUS command from any menu.
4. How do you save data in BDC tables?
The data in BDC tables is saved by using the field name ‘BDC_OKCODE’ and field value of ‘/11’.
5. What is the last entry in all BDC tables?
In all BDC tables the last entry is to save the data by using the field name BDC_OKCODE and a field value of ‘/11’.
6. What is a multiple line field?
A multiple line field is a special kind of field which allows the user to enter multiple lines of data into it.
7. How do you populate data into a multiple line field?
To populate data into a multiple line field, an index is added to the field name to indicate which line is to be populated by the BDC session (Line index).
8. Write the BDC table structure.
BDC table structure
FIELD TYPE DESCRIPTION
Program CHAR (8) Program name of transaction.
DynPro CHAR (4) Screen number of transaction.
DynBegin CHAR (1) Indicator for new screen.
Fnam CHAR (35) Name of database field from screen.
Fval CHAR (80) Value to submit to field.
9. Does the CALL TRANSACTION method allow multiple transactions to be processed by SAP?
No. The CALL TRANSACTION method allows only a single transaction to be processed by SAP.
10. Does the BDC-INSERT function allow multiple transactions to be processed by SAP?
Yes.
11. What is the syntax for ‘CALL TRANSACTION’?
CALL TRANSACTION trans [using bdctab MODE mode].
Three possible entries are there for MODE.
A - Show all screens.
E - Show only screens with errors.
N - Show no screens.
Batch Data Communication Session.
2. What are the steps in a BDC session?
The first step in a BDC session is to identify the screens of the transaction that the program will process. Next step is to write a program to build the BDC table that will be used to submit the data to SAP. The final step is to submit the BDC table to the system in the batch mode or as a single transaction by the CALL TRANSACTION command.
3. How do you find the information on the current screen?
The information on the current screen can be found by SYSTEM à STATUS command from any menu.
4. How do you save data in BDC tables?
The data in BDC tables is saved by using the field name ‘BDC_OKCODE’ and field value of ‘/11’.
5. What is the last entry in all BDC tables?
In all BDC tables the last entry is to save the data by using the field name BDC_OKCODE and a field value of ‘/11’.
6. What is a multiple line field?
A multiple line field is a special kind of field which allows the user to enter multiple lines of data into it.
7. How do you populate data into a multiple line field?
To populate data into a multiple line field, an index is added to the field name to indicate which line is to be populated by the BDC session (Line index).
8. Write the BDC table structure.
BDC table structure
FIELD TYPE DESCRIPTION
Program CHAR (8) Program name of transaction.
DynPro CHAR (4) Screen number of transaction.
DynBegin CHAR (1) Indicator for new screen.
Fnam CHAR (35) Name of database field from screen.
Fval CHAR (80) Value to submit to field.
9. Does the CALL TRANSACTION method allow multiple transactions to be processed by SAP?
No. The CALL TRANSACTION method allows only a single transaction to be processed by SAP.
10. Does the BDC-INSERT function allow multiple transactions to be processed by SAP?
Yes.
11. What is the syntax for ‘CALL TRANSACTION’?
CALL TRANSACTION trans [using bdctab MODE mode].
Three possible entries are there for MODE.
A - Show all screens.
E - Show only screens with errors.
N - Show no screens.
Subscribe to:
Posts (Atom)
-
Links to various helpful posts on SAP PI on SCN n other sites. Process Integration (PI) & SOA Middleware-SCN http://scn.sap.com/comm...
-
Function module that will take any internal table as input, convert in to XLS format and send out emails with the attachment. Add the... -
Dumps happen when an ABAP program runs and something goes wrong that cannot be handled by the program. Dumps that happen in the customer n...