Q). what is Code Review?

Before we send the source Code for testing, it should be reviewed First to avoid the frequent changes in the Source Code. Code Should be reviewed by another Sr.Team Member. The Objective of the Source Code is to make sure that the Custom Program should follow both Naming and Coding Standards.

Q). what are the Different Types of Projects in SAP? There are three types Of Projects in SAP. Implementation Project Up gradation Support Project Project

Implementation Project SAP Project which starts from the Scratch i.e. moving to the SAP Software from t he Old System. Which Contains all the below activities a) Configure the SAP System according to the Client s Organizational Unit.

b) Gather the requirements from the end users and Fix the GAPs (the differences between the Customer requirement and the solution offered in SAP) and Prepare the Functional Specification.

c) Develop the Solutions either through configure the System or through Custom Developments (Programs).

d) Test the Configuration or Programs.

e) Transport the Custom Developments to Quality/Testing Server.

f) Test custom developments again in the Testing Environment and transport it.

g) Transport it from Testing Server to Production Server.(Go-Live)

h) End User Training.

Up gradation Project It Starts, After Completing the First level Implementation , for the further De velopments and also to Change the Custom Programs to improve the Performance of the Programs and to Move from Current SAP Version to the Latest Version.

Activities: 1) Develop the Custom Developments to meet the new Customer Requirements. 2) Change the Existing Programs to Improve the Performance of the Custom Pro grams. 3) Testing and Transportation is required here also.

Support Project Note: This Phase Starts after Go-Live. The Projects, which supports the Client after Implementation. This is Post Go-li ve Activities.

Activities: 1) Provide the 24 * 7 Support to the Client/Customer s s. 2) 3) Analyze the Tickets/Issues. Solve the Tickets by changing the related Development. Day-to-Day Busines

4)

Test it and Migrate it

Q) Whom to you Communicate for the Issues / More information About Functional Specification? Ans: To the Functional Owner (Functional Consultant) who prepared the Functional Specification.

Q) When do you communicate with End Users? Ans : In the Ideal Cases, The ABAPers Never Communicate to the end users from Off-shore. ABAPer Often Communicate with them from Onsite To check the technical feasibility of the user requirements.

Q) What is Go-Live Activity? Ans: Go-Live is the Activity of transporting custom Developments from Testing En vironment to the Production Environment.

Q) What is Full Life-Cycle Implementation ? Ans: Full Life-Cycle Implementation is , Transport the Custom Developments from Development to Testing and from Testing to Production. So that , in One Project Implementation , We can Many Full-Life Cycle Implement ations.

Example : Migrating all the SD Custom Developments to Production, (Cycle1) Migrating all the MM Custom Developments to Production, (Cycle2) Migrating all the FI Custom Developments to Production (Cycle3), etc.

Q) What is Change Request? Ans: It is not the different type of transport request no. And it is not at all a transport request. The Functional Specification for the custom Development is Called Work Request a nd if the Specification is Changed to meet the additional requirements then we c all Changed Specification as Change Request.

Q) What is the time required to Develop a Report? Ans: It Completely depends on the Complexity of the Report. It Can Start from 1 Days to <n> Days. In General, The Low Complexity report takes 1 to 3 Man Days, The medium Complexity report takes 4 to 7 Man Days, The High Complexity report takes 7 to <n> Man Days. ---------------------------------------------------------------------------------------------------------------------Q) What is Extended Program Check(EPC) ? Ans: Doing an EPC would ensure the removal of mistakles we tend to overlook when we do the code-walk-through or initial testing. The program, although syntactically correct may have some unnecessary code, unus ed variables etc. EPC, advantages are

With the help of EPC we can find out the Absolete(Out Dated) stmts Authorization checks

Problematic

Statements

Any hidden messages

through this we can increase the consistency of the program and the performance can also be increased. For this Execute SE38 then program then check a EPC.

Difference Between EPC and Code Inspector : Code inspector is the tool that gives you a picture of what could be the pain po ints in terms of performance of the program. It tells you the execution time, et c, that determine the performance of the program. SCI Checks for the following:

Syntactical check

Security check

Performance check

Search Function

Extended Program Check give information of the possible errors that can cause a short dump of the program during execution like Call function interface errors, Program interface errors, etc. Also info about the translations and texts is giv en in it

Extended Program check

Any obsololete stmnt used or not

Syntactical check

3)Any unused code in the program like routines

Q) What is ASAP Methodology? Ans : The ASAP solution was developed to ensure the successful, on-time de livery of a project. SAP delivers the AcceleratedSAP (ASAP) methodology for proj ect management and system implementation.

Developed by SAP to optimize the success of implementing the SAP Business Suite, ASAP streamlines the implementation by providing templates, methods, tools, and accelerators that have been built on the success of thousands of previous SAP i mplementations. The ASAP methodology adheres to a specific road map that addresses the following five general phases:

1. Project Preparation, in which the project team is identified and mobilized, t he project standards are defined, and the project work environment is set up; 2. Blueprint, in which the business processes are defined and the business bluep rint document is designed;

3. Realization, in which the system is configured, knowledge transfer occurs, ex tensive unit testing is completed, and data mappings and data requirements for m igration are defined;

4. Final Preparation, in which final integration testing, stress testing, and co nversion testing are conducted, and all end users are trained; and

5. Go-Live and Support, in which the data is migrated from the legacy systems, t he new system is activated, and post-implementation support is provided. ASAP incorporates standard design templates and accelerators covering every func tional area within the system, as well as supporting all implementation processe s.

Q). What is Code Inspector? Ans : The Code Inspector (transaction code SCI) is a tool for checking Repositor y objects regarding performance, security, syntax, and adherence to name convent ions.

Using the Code Inspector (transaction code SCI), you can check individual object s or Set Of Objects for performance, security, syntax, and adherence to name con ventions.

There are messages that are always important, that always need action,like:

-> performance error and warning messages regarding missing index support;

-> select single statements without fully qualified key

-> calling functions with a wrong interface (will lead to run time errors)

-> submitting programs and calling transactions that do not exist

-> using obsolete statements (like on change) and functions (like ws_download)

-> subroutines with not typed formal parameters

-> bad error handling: no checking of return codes after SQL statements, CALL FUNCTION statements etc -> inefficient internal table use (sequential access to internal tables will lea d to serious performance problems if the internal table is large and the access is done repeatedly)

Q) What is OSS Note? Ans : Problems could not be solved by both of the above, are referred to Online Service Support (OSS) of SAP Itself. SAP tries to solve the Problem, sometimes by providing the perfect OSS Notes, fi ts to the error and rarely SAP logs into our Servers (via remote log-on)for post mortem the problem.

(The Medical check-up client, connections, Login id and Passwords stuff are to b e provided to SAP whenever they need or at the time of opening OSS Message.) There are lots of OSS Notes on each issue, SAP Top Notes and Notes explaining ab out the process of raising a OSS Message. Sometimes SAP Charges to the client / Service company depending on the Agreement made at the time of buying License from SAP.

Note : We Can check all the available OSS Notes through SAP Transaction SNOTE. ------------------------------------------------------------------------------------------------------------Q).What is Onsite and Offshore? Onsite : Is the Client s Place. Some Functional Consultants and Senior Technical(ABAP) Cons ults works here.

Role of Functional Consultants : a) Functional consultants Customize the SAP System i.e. Define the Client s Organi zation Structure in SAP. b) The Functional Consultants Discuss with the End Users and Gather the require ments and Analyze them and Suggest the already available Solutions in SAP and tr ain them on the same at end of the Project Implementation through End User Trai ning. c) Functional Consultants Fix the GAPs (The Differences Between the Current Req uirements and the Solutions available in SAP, Because the SAP Solutions may fit to the User Requirements Exactly. d) Document the Above requirement i.e. FS(Functional Specification). e) Test the Custom Development with Functional Test Cases and also Prepare the Test Data .

ODC(Offshore Development Center ) Is the Software Organization which implements SAP for the Clients . Ex: Satyam Computers, Infosys, CAP Gemini etc..

Q).What is Issue Log ? Ans : It is the Document to Log all the Issues

SNO 1

ISSUE

DEVLOPVER

RESOLUTION 28.06.07

DATE

And the Same will be sent to the Onsite for Resolution.

Q). What is Flow of Work in your Project ? Ans : It Includes all the area where the ABAPer Involves. -> Receive the Functional Specification from Onsite. -> Either we receive the FS Directly from the Technical Consultant through Mail or we need to Download the Same from the Client s Site If Available. -> Analyze the FS and Prepare the Brief and Detailed Technical Specification. Issues

-> Log the Issues in a Issue Log. (an EXCEL Document to Maintain the ) and Send the same to the onsite. ->

Send the TS to Onsite for Validation .Start the Coding Simultaneously.

-> Discuss with Onsite people for the Issues Clarification if the Issues not res olved in time.(When the Issue is not turned back from Onsite with Solutions in T ime). -> After Completion of the Source Code,Send it for Code Review and Prepare the o ther Delivery Documents -> Rework after Code review and Quality Check and Complete it.

-> Inform to your team lead about the Completion of the Same, So that we can as k the Onsite People for Testing. -> Rework After Testing if Any. -> Release the Custom Development (Corresponding Request No).

Q). Who is your Team Lead , Project Lead, Project Manager ? Ans : If Possible, try to gather the Correct information. If it is Really difficult to gather then give Some other friends details who can handle the situation effectively.

Q).Explain the Tickets in Support Projects ? Ans : The Issues that takes place after Go-Live(Support) are Called Tickets. Tickets come into Picture in Support Projects Only. Note : The Tickets are divided into the below types base on their Complexity.

1. Critical.

2. Urgent. 3. High.

4. Medium 5. Low. The response times and resolution times again are defined based on the clients r equirement and the charges and . 1) First Level Ticketing: Not severe problem. Routine errors. Mostly handled by Service desk arrangement o f the company (if have one).

Eg: a) Say Credit limit block in working on certain documents?

b) Pricing Condition Record not found even though conditions are maintained?

c) Unable to print a delivery document or Packing list? Note : In the 4th phase of ASAP Implementation Methodology( i.e. Final Preparations for GO-LIVE) SAP has clearly specified that a Service desk needs to be arranged for any sort of Implementation for better handling of Production errors. Service desk lies within the client.

2) Second Level Ticketing: Some sort of serious problems. Those Could not be solved by Service Desk. Should be referred to the Service Company . Eg: a) Credit Exposure (especially open values) doesn't update perfectly to KNKK Tab le.

b) Inter company Billing is taking a wrong value of the Bill.

c) Need a new order type to handle reservation process

d) New product has been added to our selling range. Need to include this into SA P. (Material Masters, Division attachments, Stock Handling etc.)

3)

Third Level Ticketing:

Problems could not be solved by both of the above, are referred to Online Servic e Support (OSS) of SAP Itself. SAP tries to solve the Problem, sometimes by providing the perfect OSS Notes, fi ts to the error and rarely SAP logs into our Servers (via remote log-on)for post mortem the problem. (The Medical check-up client, connections, Login id and Passwords stuff are to b e provided to SAP whenever they need or at the time of opening OSS Message.) There are lots of OSS Notes on each issue, SAP Top Notes and Notes explaining ab out the process of raising a OSS Message. Sometimes SAP Charges to the client / Service company depending on the Agreement made at the time of buying License from SAP. Eg: 1) Business Transaction for the Currency 'EUR' is not possible. Check OSS Note - This comes at the time of making Billing.

2) Transaction MMPI- Periods cannot be opened examples on the issue. 4) Fourth Level Ticketing: Where rarely, problems reach this level.

See OSS Note.There are many other

Those problem needs may be re-engineering of the business process due to change in the Business strategy. Up gradation to new Version. -----------------------------------------------------------------------------------------------------------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 e Custom Developments.

th

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 giv en 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 Qua lity/Test server.

2.QUALITY Server : Quality Server is where the core team members and other members test the customi zation 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 t hree way. Developer develop their program in Development server and then transpo rt it to test server. In testing server tester check/test the program and then t ransport it to Production Server. Later it will deploy to client from production server.

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

3.

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.

4. What is FS(Functional Specification) ? Functional Specification is the Business Requirement Specification Document whi ch 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 r equirements and Document the End users/Client requirements.

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

5.

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 R equirement. 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 Case s etc.

6. What are Delivery Documents to be prepared to Deliver the Custom Develop ment ? Note : FS is the Initial Document to start the Process.

List Of Delivery Documents : o o Brief and Detailed Technical Specification. 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. 7. 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 anot her 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 Re quest.(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.

8. 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 proc edures for naming, development, and documentation of custom solutions with the g oal 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 par ties. 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 D G I O F P N R S T U X Conversion Data Warehouse General Functionality/Other Inbound Interfaces Outbound Interfaces Inbound/Outbound Interfaces Print Program (SAPScript) Include Report System Maintenance Data Dictionary Maintenance User Exit/Validation Subroutine Pool Temporary, Demo or Test programs

Work Streams and Process Streams HR MM FI SD PP BW APO HumanResources Materials Management Finance Sales Distribution Production Planning BusinessInformationWarehouse 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, Di gits and underscore (and slash for Namespace) for Object Identifiers to avoid pr oblems (for example conflicts with wildcard characters, codepages etc.)

Note : In Realtime we receive a Document with all these details, we need llow the Same While Creating the Custom Development Objects.

to Simply fo

9. 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 i t Contains Dos and Don ts. Program Internal Objects Naming Conventions Internal program objects, such as variables, have to adhere to the following nam ing 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 Object references ABAP Objects O_ Interface references ABAP Objects IF_ Field-Symbols Dynamic symbol <*> Structures All kinds of work areas 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

DR_

WA_* or REC_* (or STRUCT_*)

Formal parameters interface of FORM routines Local classes ABAP Objects LCL_* Local interfaces ABAP Objects LIF_*

FP_*

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

MANDATORY ABAP RULES 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 a nd warnings. Use available consistency and layout check features in the screen painte r and menu painter and fix all errors and warnings. SAP-delivered objects, including tables, ABAP programs, Dynpros, SAP tra nsactions, 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 avail able to other programs by defining them with the function builder or class build er. Program structure Use the standard pattern for all programs Use header part of the standa rd 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 discret e problem. Start each new command or clause on a new line. Do not put multiple comm ands on the same line. If a statement continues past one line, indent all subseq uent lines. Skipped lines and indention should be used to promote clarity between se ctions of code as well as between definitions and processing. Keep logical secti ons 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 includ e 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 TY PE 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 in stead. Only specify an INITIAL SIZE for small internal tables (< 4kB of data) w here 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 ch apter '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, prefi x 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 speci fic text. Do not use literals or constants for texts. Allow translatability: Modularization Keep the main program short: Work with reusable, structured and small FO RMS or METHODS Even if they are not re-used (INCLUDES are not modularization uni ts). Repetitive code must be put into a modularization unit. The choice of mo dularization unit must take reusability into consideration (reuse library) Use self-explanatory English names for modularization units such as subr outines, 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 / PER FORM statement because they have no header line and a header line will automati cally 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 stan dard tables. Be aware that SAP function modules not released for external use ca n 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 diff icult When defining a new function module: Don't use the TABLES section in the f unction module interface. Instead use DDIC table types as importing, exporting o r changing parameters. Documentation EMAX program header Every program object must begin with a program header. T his includes all objects containing ABAP source code (e.g. Reports, Includes, fu nction 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 interf ace (FORMS, METHODS) must be documented with a short description. Source code Source code must be documented every 15-25 lines: Don't repeat t he source code in the documentation, explain in business language. Modifications Document all code modifications (custom programs and SAP program s): Update the change history in the program header and document each change. Se e examples in chapter 'Recommendations'. Dependent objects If there are objects that are related to the same develo pment, then they should be listed in the header comment, this is especially rele vant for Workplace developments. For programs and routines that are called from specific locations, inclu ding user exits, the documentation must indicate the calling program or routine. Operations DIVIDE , etc. to make code more COMPUTE Don't use COMPUTE statement as well as ADD , readable X = X + 2. IMPORT EXPORT Use IMPORT/EXPORT TO/FROM MEMORY only if no other technique is a vailable for data exchange. Always use the addition ID. It must be documented wh ere data is used (IMPORT: Where was data exported, EXPORT: Where will data be im ported). 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 st atements (see online help for details) Rule: Avoid using ABAP language, which is not supported in the ABAP Objects cont ext. 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, MK PF, 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 ... ENDSELE CT (Use array operations (e.g. INTO TABLE) No SELECT within loops (load data into int. table and read record with READ TABL E ... WITH TABLE KEY ...) Do not use UPDATE, INSERT, etc. within loops (use UPDATE, INSERT, etc. FROM TA BLE ...) Keep overhead in DB small Use of primary or secondary DB index appropriate ly 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 tabl e)

Avoid using 'SELECT INTO CORRESPONDING FIELDS' as the associated overhea d 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 ena bling hashed- or binary search (READ TABLE ... WITH TABLE KEY or LOOP ... WHER E) Error Handling All programs must include proper error handling to avoid undesirable ter minations. This means that the return code (SY-SUBRC) must be checked after ever y statement in the program that changes it. Always handle all exceptions of a function module call. Only if it is en sured, that the function module actually issues messages, handle the exceptions with the default message statement. Otherwise handle all exceptions with your ow n error messages. In dialog programs, to handle a lock entry failure, raise an error messa ge (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 o bject. To minimize the impact on users, limit retries. DDIC If no special requirements exist for maintenance of custom table content s always create the table maintenance and associate a transaction code. Dynpro programming Use Data Dictionary names (short, medium, long) for field text on screen s where applicable. Use 'SAVE_OK_CODE' as the field name when saving the OK Code field. It i s recommended that you use a backup version of the OK Code field to avoid sendin g 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 fo r regular dynpros. Report output design Include the following information in the output list to give users a cle ar indication as to what the report consists of: End-User Reports: selection criteria, entries found, requester, report name, dat e/time, exceptions, parameters, etc. Conversion/Interface Reports: number of records read, number of records processe d, 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 pro cessing 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 inter nal 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 rea d/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 DO v_fact TIMES. v_res = v_res / v_fact. "<- COMPUTE_OVERFLOW v_fact = v_fact ENDDO. 1. 1.

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 u sed 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 tra nsports 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 inter nal 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 quer y, 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. Avo id 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 reco rds you MUST secure that your program handles DB commits at a reasonable frequen cy.

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 databas e and eventually the whole system will be deadlocked. Shutting down the system i s the only option left to terminate the execution as your program consumes all r esources.

Regarding commit be aware of the enqueue / dequeue logic for table locks and ens ure 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 Po ints (type F) require more time, and Packed (type P) are the most expensive. Nor mally, 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 field s 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 c orresponding 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 ... ENDLO OP, SELECT ... ENDSELECT). Especially within INCLUDE programs, CHECK may be dang erous. 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 shou ld handle exceptions and process messages. Don't use MESSAGE otherwise in RFC fu nction 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. W hen 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 ch ecking 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 situati on 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 languag e.

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 followi ng rules. Revisions should be documented at the beginning of the program as in t he program template Single line changes: Copy the line and convert the original line to a comment line and note it with t

he revision number. Make the changes and then also mark the new line with the re vision 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 c lass. Therefore a list of modifications for the function group must be placed in the top include.