Your contribution can keep this blog alive!!!

Saturday, 5 January 2013

SAP Project Management Realtime Interview Questions Answers






SAP Project Realtime Interview Questions Answers
SAP Project Management Realtime Interview Questions and Answers, ABAP Project Interview Questions.

Dear ABAPER's in this post we are going to provide a list of SAP ABAP Project Real time Questions and Answers which are asked in various interviews by the top MNC companies. 

SAP Project Interview Questions and Answers

This post includes real time questions on Projects, Types of Projects, System Landscape of project, Team size, Issues related to Projects, Ticketing in Projects and other objects. This post definitely will help the ABAPers who are going to attend interviews with 2+ and 3+ experience. Dear ABAPers refer this post for more details. 




1. What is SAP R/3 Real time Landscape ?

  
Landscape : is the arrangement for the servers


DEVELOPMENT ---> QUALITY Server ----> PRODUCTION Servers

Development  
                                            
Quality/Testing 
                       
Production/Go-Live

  
DEVELOPMENT :

is where the consultants do the customization as per the company's              requirement and also the Custom Developments by ABAPers.




Note :    

ABAPers  always get access Only  to Development Server for Custom  Developments.



  
QUALITY : 


is where the core team members and other members test the customization and   the Custom Developments.

    

  

PRODUCTION : 


is were the live data of the company is recorded. 

    

  
Note : 

A request will flow from Dev->Qual->Prod and not backwards.
Sandbox server: In the initial stages of any implementation project, You are given a and box server where you do all the configuration/ customization as per the companies business process.


1.Development Server:

Once the BBP(Business Blue Print) gets signed off, the configuration is done is development server and saved in workbench requests, to be transported to the Quality/Test server.


2.QUALITY Server : 

Quality Server is where the core team members and other members test the customization and the Custom Developments and Transport to Production Server.


3.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.


These three are landscape of any Company. They organised their office in these three way. Developer develop their program in Development server and then transport it to test server. In testing server tester check/test the program and then transport it to Production Server. Later it will deploy to client from production server.


  1. What is Size of Your Team ?
The Team Size Can vary from  10 to 100 and 200 etc..
The Team Size , generally refers to Only the ABAP Team
And the Project size Includes all the teams from each Module.


Note : 
There is no stringent rules on the team Size.
You Can give  any Number BUT Be CONFIDENT of the  answer.


  1. What is Your Role in the Current Project ?
      To be frank, it depends on your Experience.


As we already Discussed, the answers are prepared for the Candidates those 

appear for the interview with 2 to 3 Years Of Experience.


     The Generic roles with 2 to 3 Years experience


·          Analyze FS and Prepare Brief TS
·          Prepare the Detailed TS from the  FS or Brief FS.
·          Coding
         ·          Discussions with Functional People while Preparing the TS to
                      understand more about the FS.
·         Code Review
·         Transporting the Custom Developments.


Note : If you are more Confident, You can also Project yourself as a  
Team Lead for a Small Team.


  1. What is FS(Functional Specification) ?
Functional Specification is the  Business Requirement Specification Document which is Prepared by the Functional Consultant.

This is also Called as GAP (The GAP Between the Current Organization’s Requirement and the Solutions available in SAP) .

This Can be Prepared Only after discussing With end users and understand their requirements  and Document the End users/Client requirements.


Note : It is Simply a  MS word Document which Carries the Client’s requirement.


  1. What is TS(Technical Specification)   ?
     Is a Document , Prepared  by the Technical Consultant (ABAPer).

This Contains all the technical details such as the technical solution for the Requirement.

The Detailed Technical Specification Contains all the details such as
Starting from Designing Selection Screen, Declarations, all the Function Modules used and the Processing Logic to meet the Customer requirements, Unit Test Cases etc.


  1. What are Delivery Documents to be prepared to Deliver the Custom Development ?

Note : FS is the Initial Document to start the Process.
           

List Of Delivery Documents :

o   Brief and Detailed Technical Specification.

o    UTP (Unit Test Plan)

o     Document which provides the Transport request Details.
And You can have More documents which really depends on the The Project.

  1. How to Transport your Object(Custom Development)
From the Current Environment to the Other Environment ?

Note : To Transport the Custom Development from One     Environment(DEV) to another Environment(TEST) , the Object should be Eligible for transport.

Eligibilty1 :

The Object should be transportable Object(Not Local Object), i.e.  it should not be saved in Development Class/Package $TMP(Local Object).

Eligibilty2 :

           Each Development should be linked with one Transport Request No.
            And Each Request No has one Task No , Which Actually carry the
            Custom Developments.
           

Note1 :  

To Transport the Developments, We need to release the Corresponding Task  and Request.(Task Should be Released Before the Request) and

The copy of the development will be migrated as per the  Configuration(Routings ) Defined in TMS(Transport Management System).


Note 2:  

Release Procedure :
           
Execute SE09 -> Right Click on the Task and Click On Release Directly Option And repeat the same for Transport Request No Also.



  1. What is Naming Standards and how it helps in Custom Development ?
 Naming Standards Contains the rules to Provide the Names
      For all the Custom Developments and the Declarations etc.


Ex:
Custom Program Names,

                  Custom Table Names,

                  Custom Data Elements , 

                  Domain Names,

                  Functional Module Names etc.
                 
Note : 

This is the First Document you receive when You join in any Project.



Objective :

The purpose of this document is to articulate a common set of standards and procedures for naming, development, and documentation of custom solutions with the goal of maximizing the quality, value and maintainability of each custom solution. 

SAP OBJECT NAMING CONVENTIONS

FUNDAMENTAL RULES

As of Release 4.0, SAP customers and partners can obtain their own namespace for their customer developments, which are to be delivered to independent third parties. Thus naming conflicts can be avoided during the delivery.

                                         
Development Namespaces
Standard SAP
Partner/Customer

A – X, 1 – 8
Before 4.0: Z_
As of 4.0:   /<3 – 8 digits>/


Ex : /Reddy Labs - For all Reddy Labs Custom  Developments.


Reference(Source) Tables for all Naming Conventions:


PROGRAM TYPES


C
Conversion
D
Data Warehouse
G
General Functionality/Other
I
Inbound Interfaces
O
Outbound Interfaces
F
Inbound/Outbound Interfaces
P
Print Program (SAPScript)
N
Include
R
Report
S
System Maintenance
T
Data Dictionary Maintenance
U
User Exit/Validation Subroutine Pool
X
Temporary, Demo or Test programs

Work Streams and Process Streams


HR

HumanResources

MM

Materials Management

FI

Finance

SD

Sales Distribution

PP      

Production Planning

BW

BusinessInformationWarehouse

APO

Adnace Planner &Optimizere    etc..

 

General Naming Conventions


Position

Description

1 – 5
Name Space
6  - 7
Process/Module (MM/SD/HR)
 8
Program  Type
9 – possible length
descriptive text;
it is recommended to start with an underscore ‘_’ In general use only Characters, Digits and underscore (and slash for Namespace) for Object Identifiers to avoid problems (for example conflicts with wildcard characters, codepages etc.)


Note : 

In Realtime we receive a Document with all these details, we need   to Simply follow the Same While Creating the Custom Development Objects.


  1.  What is the Coding  Standards and how it helps in Custom Developments?
 Coding  Standards are the rules to develop the Source Code.The Objective of the Coding Standards are to Delivery the Quality Source Code.


Note : 

Even though each project has their own Coding Standards , all most
                  All the project follows the Similar coding Standards Because it
                  Contains Dos and Don’ts.


Program Internal Objects Naming Conventions

Internal program objects, such as variables, have to adhere to the following naming conventions, regardless if they occur in Reports, Methods, Workflow, etc.





Program Element
Use
Syntax
Types
General
TY_*
Constants
General
C_*
Variable
Counters
CNT_*
Flags
FLG_*
Sums
SUM_*
All others
V_*
Data references

Dynamically created data objects
DR_
Object references
ABAP Objects
O_
Interface references
ABAP Objects
IF_
Field-Symbols
Dynamic symbol
<*>
Structures
All kinds of work areas
WA_* or REC_* (or STRUCT_*)
Internal tables
Internal tables:
 - Standard table

I_*
 - Sorted table
IS_*
 - Hashed table
IH_*
Copy of database table
Y_* or Z_*[1]
Ranges
General
R_*
Local declaration
Statics
All others
ST_*
L_xxx_*
xxx      prefix (e.g. CNT, TY, I, etc.)
Select Options
in selection-screens
S_*
Parameters

in selection-screens
 - Radio Buttons
 - Check Boxes
P_*
RB_*
CB_*
Other Screen Elements (Dynrpo)

- Push Buttons
- Radio Buttons
- Check Boxes
- Controls for tabstrip
- Controls for tablecontrol
- OK - Field 
PB_*
RB_*
CB_*
TS_*
TC_*
OK_CODE
Formal parameters
interface of FORM routines
FP_*
Local classes
ABAP Objects
LCL_*
Local interfaces
ABAP Objects
LIF_*





Note: 

The asterisk in the table above signifies a descriptive name of your choosing. Consider using an underscore (_) to connect multi-word variable.



Developments will be inspected by QA after these mandatory rules.

Every object must be checked against this list of rules before it is delivered. 

This Process is ensured by the QA(Quality Analyst) from ODC(Offshore Development Center).

Violations against this list of  Mandatory rules must be analyzed and Documented.

Category

Rule

OK
Development process



Use the code inspector or the extended syntax check and fix all errors and warnings.


Use available consistency and layout check features in the screen painter and menu painter and fix all errors and warnings.


SAP-delivered objects, including tables, ABAP programs, Dynpros, SAP transactions, etc. cannot be modified according to the current Program Modification Policy.

Re-usability



Program logic, which is a candidate for reusability has to be made available to other programs by defining them with the function builder or class builder.

Program structure



Use the standard pattern  for all programs – Use header part of the standard pattern for all other development objects containing ABAP source code.


Program logic must be structured, simple and short:
1. Declaration including class definition (possibly in TOP include)
2. Main Processing
            - Read data and store in internal data objects (e.g. int. table)
            - Process data
            - Output data
3. Subroutines / class implementation (possibly in include)


Don't mix code and declaration in the processing part.


Use pretty printer.


Keep program length to a minimum. Each program should handle one discrete problem.


Start each new command or clause on a new line. Do not put multiple commands on the same line. If a statement continues past one line, indent all subsequent lines.


Skipped lines and indention should be used to promote clarity between sections of code as well as between definitions and processing. Keep logical sections together by using empty lines or comment  lines.


In every program a default message class must be specified.

Data declaration



Global data must be encapsulated in a TOP-Include in general. The include name should be the same as the program name with the suffix ‘_TOP’. Exceptions are small programs.


Data objects must be declared with an appropriate reference to a DDIC TYPE or a program internal TYPE. Don't  define data objects with the option LIKE.


The TABLES statement is not allowed except for a DYNPRO interface.


Don't use literals – always use constants.


Internal tables must not have header lines. Also, don't use the addition OCCURS as it is no longer supported in the ABAP OO context.  Use INTIAL SIZE instead.


Only specify an INITIAL SIZE for small internal tables (< 4kB of data) where the number of expected rows is known, otherwise omit this addition. 


Internal tables must be defined with the appropriate table type based on usage (HASHED, SORTED, STANDARD).


Follow the naming conventions for all internal program objects as per chapter 'Naming conventions for program internal objects'.


Always keep the SAP names. DO NOT “translate”.  If you need the same type of data from different tables like document numbers for different documents, prefix the name with the table name like:
            WA_VBAK_VBELN                       “Sales Order No.
            WA_LIKP_VBELN             “Delivery No.





Multi language capability



Use text elements, selection texts and messages to define language specific text. Do not use literals or constants for texts.  Allow translatability:

Modularization



Keep the main program short: Work with reusable, structured and small FORMS or METHODS – Even if they are not re-used (INCLUDES are not modularization units).


Repetitive code must be put into a modularization unit. The choice of modularization unit must take reusability into consideration (reuse library)


Use self-explanatory English names for modularization units such as subroutines, methods, etc. Use underscores (_) to connect multi-word modularization unit names.


Subroutine interface parameters (formal parameters) must be typed.


Don't pass an internal table using the TABLES addition of the FORM / PERFORM statement because they have no header line  and a header line will automatically be created – use the addition USING or CHANGING instead.


Don't use global variables in subroutines. Always pass actual parameters to the subroutine.


Do not use unreleased SAP function modules, which do updates to SAP standard tables. Be aware that SAP function modules not released for external use can be changed by SAP without further notice.


External PERFORM must NOT be used.


Don't use INCLUDE in methods. Use private methods for modularization in BADIs.


Don't use macros as they reduce readability and make debugging more difficult


When defining a new function module: Don't use the “TABLES” section in the function module interface. Instead use DDIC table types as importing, exporting or changing parameters.

Documentation


EMAX program header
Every program object must begin with a program header. This includes all objects containing ABAP source code (e.g. Reports, Includes, function modules, etc.)


Copied programs shall have a reference to the cloned program.

Declaration
All data objects must be documented.

Modularization units
All internal modularization units including their interface (FORMS, METHODS) must be documented with a short description.

Source code
Source code must be documented every 15-25 lines: Don't repeat the source code in the documentation, explain in business language.

Modifications
Document all code modifications (custom programs and SAP programs): Update the change history in the program header and document each change. See examples in chapter 'Recommendations'.

Dependent objects
If there are objects that are related to the same development, then they should be listed in the header comment, this is especially relevant for Workplace developments.


For programs and routines that are called from specific locations, including user exits, the documentation must indicate the calling program or routine.

Operations


COMPUTE
Don't use COMPUTE statement as well as “ADD”,  “DIVIDE”, etc. to make code more readable ® X = X + 2.

IMPORT EXPORT
Use IMPORT/EXPORT TO/FROM MEMORY only if no other technique is available for data exchange. Always use the addition ID. It must be documented where data is used (IMPORT: Where was data exported, EXPORT: Where will data be imported).
Also, use a business term for the Memory ID.

IF – CASE
For better readability, use CASE instead of IF, especially if more than 4 different values are checked. To optimize IF and CASE structures, always test values in order of the likelihood of each value occurring.

General


Obsolete Statements
Don't use obsolete statements or obsolete variants of statements (see online help for details)
Rule: Avoid using ABAP language, which is not supported in the ABAP Objects context.

SQL



Follow the "golden rules" for SQL programming:

Keep hit-set small
  • Use good (possibly positive) WHERE clause
  • Do not use SELECT ... CHECK ... (incorporate CHECK into WHERE clause)
  • Do not use SELECT without WHERE clause for tables that grow constantly (BSEG, MKPF, VBAK, etc.)
Keep amount of data to be transferred small
  • Do not use SELECT * (use SELECT f1, f2, etc. )
  • Use aggregates (SUM, AVG, etc.)
  • Update only the fields, which have been changed
Keep number of DB accesses small
  • Do not use SELECT ... APPEND ... ENDSELECT (Use array operations (e.g. INTO TABLE)
  • No SELECT within loops (load data into int. table and read record with READ TABLE ... WITH TABLE KEY ...)
  • Do not use UPDATE, INSERT, etc.  within loops (use UPDATE, INSERT, etc.  FROM TABLE ...)
Keep overhead in DB small
  • Use of primary or secondary DB index appropriately
Avoid unnecessary DB accesses
  • No re-reads
  • Use table buffering
  • Don't ORDER BY (sort data in internal table e.g. by using a SORTED internal table)





Avoid using 'SELECT … INTO CORRESPONDING FIELDS' as the associated overhead with 'CORRESPONDING FIELDS' could be significant.


Check the return code after every SQL statement


NEVER use native SQL.


NEVER update SAP standard DB tables in custom programs.


When creating a program that writes new or updates existing records you MUST secure that your program handles DB commits at a reasonable frequency.


Do not create lock objects for SAP standard tables

Working with internal tables



Direct access to an internal table within loops must be optimized by enabling hashed- or binary search (READ TABLE ... WITH TABLE KEY  or  LOOP ... WHERE)

Error Handling



All programs must include proper error handling to avoid undesirable terminations. This means that the return code (SY-SUBRC) must be checked after every statement in the program that changes it.


Always handle all exceptions of a function module call. Only if it is ensured, that the function module actually issues messages, handle the exceptions with the default message statement. Otherwise handle all exceptions with your own error messages. 


In dialog programs, to handle a lock entry failure, raise an error message (type E) preventing any further progress but leaving the user on the current screen. The user can take an alternative action or continue to try to lock the object. To minimize the impact on users, limit retries.

DDIC



If no special requirements exist for maintenance of custom table contents always create the table maintenance and associate a transaction code.

Dynpro programming



Use Data Dictionary names (short, medium, long) for field text on screens where applicable.


Use 'SAVE_OK_CODE' as the field name when saving the OK Code field. It is recommended that you use a backup version of the OK Code field to avoid sending a screen that already has a function code.


Screen numbering must follow functionality, such as:
9000 – Initial screen
9100 – Block 1
9110 – Sub-functionality of Block 1
9120 – Sub-functionality of Block 1 

Selection screen design



Screen numbering for additional selection screens has to follow rules for regular dynpros.

Report output design



Include the following information in the output list to give users a clear indication as to what the report consists of:
  • End-User Reports: selection criteria, entries found, requester, report name, date/time, exceptions, parameters, etc.
  • Conversion/Interface Reports: number of records read, number of records processed, number of records written, date/time, transactions posted, etc.


  

Coding Guidelines(Standards)

ABAP Programming Hints and Examples







Category


Hints and recommendations

Working with internal tables: Field-Symbols







Working with field-symbols increases the performance by 30%-50% when processing internal tables:





DATA: i_customer TYPE SORTED TABLE OF ty_customer

WITH UNIQUE KEY kunnr.





FIELD-SYMBOLS: <cust> TYPE ty_customer.





LOOP AT i_customer ASSIGNING <cust>.

WRITE: / <cust>-KUNNR,

<cust>-NAME1.

ENDLOOP.





Working with field-symbols increases the performance when updating internal tables. Also no modify is required.





CONSTANTS: c_x TYPE char1 VALUE 'X'.





DATA: i_customer TYPE SORTED TABLE OF ty_customer

WITH UNIQUE KEY kunnr.





FIELD-SYMBOLS: <cust> TYPE ty_customer.





LOOP AT i_customer ASSIGNING <cust>.

<cust>-MARKED = c_x.

ENDLOOP.



Internal table types















Overview

Table type Usage
STANDARD Memory dump; no sorting, no reading required, fill sequentially, process sequentially, access time linear

SORTED Sorted output, unique/non-unique key possible, performance optimized read/loop with partial/full key, access time logarithmic

HASHED Look-up table, unique key only, performance optimized reads with partial/full key, access time constant



Catching system-exceptions



















Catching a "short-dump"





CATCH SYSTEM-EXCEPTIONS ARITHMETIC_ERRORS = 5.





v_res = v_fact_save = v_fact.

v_fact = v_fact – 1.


DO v_fact TIMES.

v_res = v_res / v_fact. "<- COMPUTE_OVERFLOW

v_fact = v_fact – 1.


ENDDO.





ENDCATCH.





IF sy-subrc = 5.

WRITE: / TEXT-001. "'Overflow!


ELSE.

WRITE: / TEXT-002,


v_fact_save,

TEXT-003,

v_res.

ENDIF.






Note: List of catchable exceptions: See Help.
CALL FUNCTION error handling When a function call is inserted into the source code using the pattern button, then default error handling is copied as follows:





IF sy-subrc <> 0.

* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO

* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

ENDIF.





Replace default message statement with specific error handling.





e.g.





CASE sy-subrc.

WHEN 1.

MESSAGE e006(/emax/msgid) WITH v_storage.

* Packing Storage type & does not exists

WHEN 2.

...

ENDCASE.



Performance optimized SQL Keep the hit-set small:

Don't access records from the DB to the application server memory, which is are not used for further processing.



Don't



Do




SELECT CARRID CONNID

FROM SBOOK INTO WA_SBOOK.

CHECK:

WA_SBOOK-CARRID = 'LH' AND

WA_SBOOK-CONNID = '0400'.

ENDSELECT.











SELECT CARRID CONNID

FROM SBOOK INTO WA_SBOOK

WHERE CARRID = 'LH' AND

CONNID = '0400'.

ENDSELECT.



Performance optimized SQL Keep amount of data to be transferred small:

Don't transfer data from the DB to the application server memory, which is not used for further processing



Don't



Do








SELECT *

FROM DD01L

INTO WA_DD01L

WHERE DOMNAME LIKE 'CHAR%'

AND AS4LOCAL = 'A'.

ENDSELECT.











SELECT DOMNAME

FROM DD01L

INTO WA_DD01L-DOMNAME

WHERE DOMNAME LIKE 'CHAR%'

AND AS4LOCAL = 'A'.

ENDSELECT.



Performance optimized SQL Keep number of DB accesses small

Transfer data from DB server to application server at once. Multiple smaller transports are more expensive.

Don't Do








DATA WA_T006 TYPE T006.

CLEAR I_006[].

SELECT *

FROM T006

INTO WA_T006.

APPEND WA_T006 TO I_006.

ENDSELECT.











SELECT *

FROM T006

INTO TABLE I_006.                 



Performance optimized SQL Keep number of DB accesses small

Avoid SELECT SINGLE ... between LOOP and ENDLOOP, especially for larger tables (>100 rows). It is more efficient to load data from multiple DB tables into internal tables and process them in the application server memory.



Don't


Do 
                                                     




DATA:

I_SFLIGHT TYPE TABLE

OF SFLIGHT,

WA_SPFLI TYPE SPFLI.





FIELD-SYMBOLS:

<SF> TYPE SFLIGHT.





SELECT * FROM SFLIGHT

INTO TABLE I_SFLIGHT.





LOOP AT I_SFLIGHT

ASSIGNING <SF>.





SELECT SINGLE *

FROM SPFLI

INTO WA_SPFLI

WHERE CARRID =

<SF>-CARRID

AND CONNID =

<SF>-CONNID.





ENDLOOP.























FIELD-SYMBOLS:

<SF> TYPE SFLIGHT,

<SP> TYPE SPFLI.





SELECT * FROM SFLIGHT

INTO TABLE I_SFLIGHT.





SELECT * FROM SPFLI

INTO TABLE I_SPFLI

FOR ALL ENTRIES

IN I_SFLIGHT

WHERE CARRID =

I_SFLIGHT-CARRID

AND CONNID =

I_SFLIGHT-CONNID.                      





LOOP AT I_SFLIGHT

ASSIGNING <SF>.





READ TABLE I_SPFLI

ASSIGNING <SP>

WITH TABLE KEY

CARRID = <SF>-CARRID

CONNID = <SF>-CONNID.





ENDLOOP.



Performance optimized SQL Keep number of DB accesses small

If possible try to retrieve the data with one SQL statement (e.g. JOIN, sub query, etc.). Avoid nested select statements.




Don't


Do



SELECT *

FROM SPFLI

INTO WA_SPFLI.





SELECT *

FROM SFLIGHT

INTO WA_SFLIGHT

WHERE CARRID =

WA_SPFLI-CARRID

AND CONNID =

WA_SPFLI-CONNID.

ENDSELECT.





ENDSELECT.





SELECT P~CARRID P~CONNID

S~FLDATE

INTO TABLE I_FLI

FROM SPFLI AS P

INNER JOIN SFLIGHT AS F

ON P~CARRID = F~CARRID

AND P~CONNID = F~CONNID.              











Performance optimized SQL Keep overhead in the DB small

Always take advantage of existing DB indexes. Use a good and simple where – clause: Positive (=, >, <, etc.). Make sure an index can be used from the left to the right.





If no index can be used, then the DB system executes a full table scan.

Don't Do                                                 








DATA: WA_MSG TYPE T100.





SELECT *

FROM T100

UP TO 1 ROWS

INTO WA_MSG

WHERE SPRSL = SY-LANGU

AND MSGNR = '999'

AND ARBGB <> 'V0'.





ENDSELECT.











DATA: WA_MSG TYPE T100.





SELECT *

FROM T100

UP TO 1 ROWS

INTO WA_MSG

WHERE SPRSL = SY-LANGU

AND MSGNR = '999'

AND ARBGB = 'V0'.





ENDSELECT.



Performance optimized SQL Avoid unnecessary DB accesses





The access time is accelerated if buffered tables are accessed.





The following statements cannot use SAP table buffer support:





- BYPASSING BUFFER

- ORDER BY

- SELECT DISTINCT

- JOIN and SUBQUERIES

- aggregate functions (e.g. SUM, AVG, MIN, MAX.)

- WHERE ... IS [NOT] NULL


Don't Do








SELECT DISTINCT *

FROM T100

INTO T100_WA

WHERE SPRSL = 'D'

AND ARBGB = '00'

AND MSGNR = '999'.

ENDSELECT.











SELECT SINGLE *

FROM T100

INTO WA_T100

WHERE SPRSL = 'D'

AND ARBGB = '00'

AND MSGNR = '999'.                              





SQL – Existence-check









Check DB table for existence of rows for a given condition.


Don't Do








SELECT SINGLE COUNT( * )

FROM DD02L

WHERE MASTERLANG = 'E'.



















DATA:

V_TABNAME TYPE TABNAME.





SELECT TABNAME

INTO V_TABNAME

FROM DD02L

UP TO 1 ROWS

WHERE MASTERLANG = 'E'.

ENDSELECT.
                                           



Note: Our example uses a DB table with 150000 rows. The UP TO 1 ROWS example is 600 times faster.

LUW control Check return code after inserts, updates, delete and modify. Avoid implicit commit:





UPDATE sflight

SET seatsocc = seatsocc + 1

WHERE carrid = c_lufthansa.





IF sy-subrc = 0.

COMMIT WORK.

MESSAGE s009(bc_bor).

* Change successful

ELSE.

ROLLBACK WORK.

MESSAGE i008(bc_bor).

* Error when changing

ENDIF.





LUW control


Updates are carried out by function module in update task:

* Log V1 update module in LUW

CALL FUNCTION 'Y_UPDATE_SFLIGHT'

IN UPDATE TASK

EXPORTING

im_sflight = wa_sflight.





* Start update task

COMMIT WORK.



FUNCTION y_update_sflight.

*"----------------------------------------------------------*"*"Update function module:

*"

*"*"Local interface:

*" IMPORTING

*" VALUE(IM_SFLIGHT) TYPE SFLIGHT

*"----------------------------------------------------------

UPDATE sflight FROM im_sflight.





IF sy -subrc <> 0.

MESSAGE a008(bc_bor). " <-- ROLLBACK if called in

" update task

* Error when changing

ENDIF.





ENDFUNCTION.



LUW control When creating a program that writes new or updates existing records you MUST secure that your program handles DB commits at a reasonable frequency.





As a general rule, you should do a commit every 1000 or 10 000 records. If your program is running for a long period of time without doing a commit, the database and eventually the whole system will be deadlocked. Shutting down the system is the only option left to terminate the execution as your program consumes all resources.





Regarding commit be aware of the enqueue / dequeue logic for table locks and ensure that only consistent data is updated with commit work!




Calculations




When performing calculations in ABAP, the amount of CPU time used depends on the data type. In very simple terms, Integers (type I) are the fastest, Floating Points (type F) require more time, and Packed (type P) are the most expensive. Normally, Packed number arithmetic is used to evaluate arithmetic expressions. If, however, the expression contains a floating point function, or there is at least one type F operand, or the result field is type F, floating point arithmetic is used instead for the entire expression. On the other hand, if only type I fields or date and time fields occur, the calculation involves integer operations.





Since floating point arithmetic is relatively fast on SAP hardware platforms, it should be used when a greater value range is needed and rounding errors can be tolerated.





Rounding errors may occur when converting the external (decimal) format to the corresponding internal format (base 2 or 16) or vice‑versa.



Operations Avoid MOVE-CORRESPONDING wherever possible:

Moving identical structures:



Avoid


Better 
                                             
MOVE-CORRESPONDING

struct_xxx TO struct_yyy.


struct_yyy = struct_xxx.

Moving identical internal tables (without header lines)



Recommendation


i_yyy = i_xxx.                                                                               


Moving identical internal tables (with header lines)



                                  


                                       Recommendation  
                                                                      


                                    
                                       i_yyy[] = i_xxx[].                                



CHECK


Avoid CHECK within user-exits

Avoid Better                                                       




CHECK sy-subrc = 0.







IF sy-subrc = 0.

PERFORM ...

ENDIF.





CHECK sy-subrc = 0 

is the same as

IF sy-subrc <> 0. EXIT. ENDIF.



Negative result of a CHECK leaves the processing block or modularization unit (e.g. FORM, FUNCTION MODULE, EVENT), unless CHECK is within a loop (LOOP ... ENDLOOP, SELECT ... ENDSELECT). Especially within INCLUDE programs, CHECK may be dangerous.


Hint: If it is desired to leave a processing block, use RETURN

DESCRIBE Checking if an internal table is empty

Don't Do                                                




DESCRIBE i_xxx LINES v_lin.

IF v_LIN = 0.

...

ENDIF.




IF i_xxx IS INITIAL.





ENDIF.





*) i_xxx has no header line
FREE / CLEAR / REFRESH Deleting rows of an internal table





Internal table is no longer used (memory can be released)



Do                                                                                                   











FREE i_xxx.


Internal table is used again

Don't Do                                                                              




FREE i_xxx.







CLEAR i_xxx.





*) i_xxx has no header line

TABLES















Don't use the TABLES statement (except for Dynpro interface)


Example: Referencing table work areas in SELECT-OPTIONS

Don't Do




TABLES: KNA1.





SELECT-OPTIONS:

S_KUNNR FOR KNA1-KUNNR.







DATA:

V_KUNNR TYPE KNA1-KUNNR.





SELECT-OPTIONS:

S_KUNNR FOR V_KUNNR.



CONSTANTS Use self explaining constant names





Don't Do




CONSTANTS:

C_7512 TYPE KSCHL

VALUE '7512'.




CONSTANTS:

C_COND_TYPE_DISCOUNT                   

TYPE KSCHL

VALUE '7512'.






RANGES Use ranges without header lines





Don't Do                                                             




RANGES:

r_matnr FOR MATNR.




DATA:

R_MATNR TYPE RANGE

OF MATNR,

WA_R_MT LIKE

LINE OF R_MATNR.



REPORT Statement Always define a message class in the REPORT statement:





REPORT /EMAX/RGTIST_TEST_PROG

NO STANDARD PAGE HEADING

LINE-SIZE 164

LINE-COUNT 65(2)

MESSAGE-ID /EMAX/RGTIS_TST_MCLSS.





MESSAGE in function modules


Use MESSAGE ... RAISING <exception> in Function modules. The calling module should handle exceptions and process messages. Don't use MESSAGE otherwise in RFC function modules (the message statement has no effect in these circumstances).



MESSAGE within SELECT ... ENDSELECT


Issuing a MESSAGE within SELECT ... ENDSELECT loops will produce a short-dump. When the data is still needed after the select, use SELECT ... INTO TABLE ... and do checking after the select. If the data is not needed after the select, do checking within the SELECT ... ENDSELECT loop but send messages thereafter.



MESSAGE design


If you define messages the long text should help the user to analyze the situation and solve possible problems. Be specific enough.


If a message does not require a long-text, then mark it as 'self-explanatory'.


For reasons of translation do never combine text-elements to create a sentence. Sequence of words in a sentence might be completely different in another language.





Documentation


All form routines should have an initial remarks section where you describe:

  • What the form routine does
  • Input/output parameters

*&-----------------------------------------------------------------*

*& Form GET_LAST_RUNDATE_TIME *

*&-----------------------------------------------------------------*

* This form is to read table ZZLRT where last run time and date *

* of this ABAP program is stored. *

*------------------------------------------------------------------*

* Parameters / Tables: *

* --> FP_JOBID Job name used to run this ABAP *

* <-- FP_REPID ABAP name *

*------------------------------------------------------------------*

FORM GET_LAST_RUNDATE_TIME

USING

FP_JOBID TYPE ty_jobid

FP_REPID TYPE sy-repid.


...


ENDFORM “Form GET_LAST_RUNDATE_TIME





Program Modifications


All program revisions (changes) must be well documented according to the following rules. Revisions should be documented at the beginning of the program as in the program template

Single line changes:

Copy the line and convert the original line to a comment line and note it with the revision number. Make the changes and then also mark the new line with the revision number.



FORM GET_LAST_RUNDATE_TIME

USING

FP_JOBID TYPE ty_jobid "MOD-001

FP_REPID TYPE sy-repid.

Multiple line changes:

Add a comment line at the beginning and the end of the block to be changed, this comment should contain the revision number and Start/End of changes. The block to be changed should be copied. The original statements should be commented out, then changes should be made in the copied block of code.



FORM GET_LAST_RUNDATE_TIME

USING

*MOD-001 BEGIN: <DESCRIPTION OF CHANGE>

FP_JOBID TYPE ty_jobid

FP_REPID TYPE sy-repid.

*MOD-001 END

Revision comments during development changes are not helpful. Too many revision comments make program harder to read.

Note: Modification numbers have to be unique within a function group or global class. Therefore a list of modifications for the function group must be placed in the top include.







"You found the information helpful and want to say thanks? Your donation is enough to inspire us to do more. Thanks a bunch!"

9 comments:

Anonymous said...

This article presents clear idea in support of the new users
of blogging, that really how to do blogging.
Feel free to visit my weblog ... suplementos para ganhar massa muscular

Anonymous said...

Terrific article! This is the type of information that should
be shared around the web. Disgrace on the search engines for
now not positioning this publish higher! Come on over and seek advice from my site .
Thank you =)
my web site :: portable tilt tower

Anonymous said...

Does YT JumpStart violate YouTube community guidelines or TOS?
my web site - here

Vikram Goud SAP Prof. said...

Excellent article...its helped me lot...

tq

Anonymous said...

Woω, awesome ωeblog lауоut!
Hοw lengthy hаve you been running a blog for? уou madе bloggіng glancе eaѕy.
The overall glance of your site iѕ great, aѕ
smaгtly as thе сontent mаteгial!
My web page: follow this link

Anonymous said...

WOW just what I waѕ sеarсhing for.
Came here by searching for channel
Also see my web page - Channeling

nasri said...

Hi

I read this post 2 times. It is very useful.

Pls try to keep posting.

Let me show other source that may be good for community.

Source: Team manager interview questions

Best regards
Jonathan.

Vijay Kumar said...

excellent job man

Vinoth Raj said...

hi tnqs for your post it really helps a lot ..

Post a Comment

Note: only a member of this blog may post a comment.

Categories

ABAP Interview Questions (107) ABAP Open SQL Statements (1) ABAP Syntax Rules (6) ABAP WORKBENCH (2) ALE IDOC (6) ALE IDOC Interview Questions (6) ALV Interview Questions (4) BADI (2) BAPI (1) BAPI Interview Questions (1) BDC (6) BDC Interview Questions (6) Classical Reports Interview Question (2) Conditional Statements (1) Cross Applications (3) Data Dictionary (22) Data Type Questins (1) Data types (1) Dialog programming (5) Dialog Programming Interview Questions (4) DOMAIN Interview Questions (1) Function Module (2) IDoc Tutorials (6) Interactive Report Interview Questions (4) Internal Tables (1) Lock Object Interview Questions (1) Logical Database (1) Modularization Interview Questions (4) Module Pool Programming (5) Object Oriented ABAP (19) Object Oriented ABAP Interview Questions (15) OOABAP (9) Reports (13) Reports Interview Questions (9) RFC (1) RFC Interview Questions (1) SAP ABAP Interview Questions (36) SAP ABAP Introduction (46) SAP ABAP Message Types (2) SAP BADI Interview Questions (2) SAP Basics (68) SAP Books (2) SAP Certification (1) SAP CONSULTANTS (5) SAP CRM (1) SAP ENHANCEMENTS (3) SAP EXITS (2) SAP EXITS ( SAP ENHANCEMENTS ) Interview Questions (1) SAP Free Books (1) SAP HR (2) SAP Lock Object (1) SAP Open SQL Statements (1) SAP R/3 Architecture (4) SAP Search help (1) SAP Smartforms (1) SAP Smartforms Interview Questions (2) SAP Tables (5) SAP Tcodes (10) SAP Views (1) SAP Webdynpro ABAP (12) SAP Work Processors (2) SAP Workflow (3) Scripts (3) Scripts Interview Questions (2) Search Help Interview Questions (1) Smartforms (1) Table Maintenance Generator (1) Tables in SAP (2) Tables Interview Questions (3) Type Group Interview Questions (1) Variable Declaration (1) Views Interview Questions (1) Webdynpro (12)

Protected Blog

 
This blog is not affiliated to SAP AG |SAP is trademark of SAP AG |The information collected from various sources use information with your own risk.