UM ABAP Development Standards Guide

2008
UM ABAP
Development
Standards
The University of Mississippi
4/01/2009

UM ABAP Development Standards 2
Table of Contents
NAMING STANDARDS ................................................................................................................... 4

PROGRAM STANDARDS ................................................................................................................ 5
DIALOG PROGRAM STANDARDS ............................................................................................... 6
1. Module Pool ............................................................................................................................ 6
2. Screens .................................................................................................................................... 6
3. GUI Status ............................................................................................................................... 6
4. Miscellaneous ......................................................................................................................... 6
TRANSACTION STANDARDS ....................................................................................................... 7
1. Reports .................................................................................................................................... 7
2. Dialog Programs ..................................................................................................................... 8
CODING STANDARDS .................................................................................................................. 10
1. Formatting ............................................................................................................................. 10
2. One command per line .......................................................................................................... 11
3. Indented source code............................................................................................................. 11
4. Variable naming .................................................................................................................... 11
5. Reusable code ....................................................................................................................... 12
6. Parameter passing in subroutine ........................................................................................... 12
7. Text handling ........................................................................................................................ 12
8. Usage of UserIDs in programs .............................................................................................. 12
9. Messages ............................................................................................................................... 12
10. Development Class ............................................................................................................. 12
11. Source Code Documentation .............................................................................................. 13
12. Function Modules ............................................................................................................... 14
PERFORMANCE STANDARDS .................................................................................................... 16
1. General Performance Standards ............................................................................................ 16
2. Performance Checking .......................................................................................................... 20
DICTIONARY: TABLE STANDARDS .......................................................................................... 21
1. User-developed table naming convention ............................................................................. 21
2. User-developed table definition convention ......................................................................... 21
3. Maintenance settings ............................................................................................................. 21
RULES STANDARDS ..................................................................................................................... 22
TRANSPORTING STANDARDS ................................................................................................... 25
1. Communication ..................................................................................................................... 25
2. Transports ............................................................................................................................. 25
3. Re-imports............................................................................................................................. 25
4. Critical Imports ..................................................................................................................... 25
TESTING STANDARDS ................................................................................................................. 27
1. Internal testing ...................................................................................................................... 27
2. Return Codes ......................................................................................................................... 27
The University of Mississippi | Confidential

3. Performance analysis ............................................................................................................ 27

4. Requestor Review ................................................................................................................. 27
AUTHORIZATIONS STANDARDS .............................................................................................. 28
PROJECT LIFE CYCLE .................................................................................................................. 29
REFERENCES ................................................................................................................................. 31

SAP Development Standards Guide
NAMING STANDARDS
1. Program names may be between 5 and 40 characters in length. Program names will be
composed of the following subfields:
a. Z — all programs must begin with the letter “Z”.
b. XX — where XX is the SAP module. Current SAP modules include:

1. AM Asset Management
2. BC Basis Component
3. BG UM Budget Preparation System
4. BI Business Intelligence
5. CO Controlling
6. CM Student Lifecycle Management
7. EP Enterprise Portal
8. FA Financial Aid
9. FI Financials
10. FM Funds Management
11. HR Human Resources
12. MB Mobius
13. MM Materials Management
14. PM Plant Maintenance
15. SE Staff Evaluations
16. TR Travel Management
17. UM global to all modules
18. other modules as designated or added to the system
c. “_” — separate the prefix from the remaining program name by an underscore
“_”.
d. If the program is for use by UMMC only, characters 5-10 must include “UMMC_”.
e. The remaining 31-36 characters may be as descriptive as you wish.
f. When writing a temporary or training program, please use the prefix “ZTST_XX_”
for the beginning of your program name. This will indicate that this program should
not be used on a regular basis in the production environment.

g.
PROGRAM STANDARDS
1. A template program ZTEMPLATE in client 110 has been provided for your convenience.
Please be careful not to update this program directly. Copy it to your new program name,
and then modify your program. Be sure to change the “Title” field on the attribute page of
your program to reflect a description of what your program does.
2. All programs should include a comment box at the beginning of the program listing the
following information (see ZTEMPLATE):
a. Program name
b. Author
c. Date written
d. Description of the program. Be sure to list any special considerations and/or
situations. List any tables being used, with a brief description of the table.
e. All modifications to the program should also be documented in this area. (See
Coding Standards: Source Code Document for more information.
3. Use descriptive data and paragraph names. Do NOT use a hyphen “-“ in variable names or
in paragraph (“form”) names. Use the underscore “_” instead. SAP uses the hyphen “-“ to
separate a table name from the field name in the table. Using an underscore will increase
readability of your program.
4. Group parameters and select-options together. Group table names together. All data items
should be at the beginning of the program before any event logic.
a. Names of parameters and select-options are limited to 8 characters.
b. Table names are limited to 16 characters.
5. Event paragraphs should be listed in a logical order inside of a START-OF-SELECTION

…END-OF-SELECTION section.
6. Use indentation to make the reading of your program easier. This is automatically set when
you use Pretty Printer (see Code Standard: Formatting).
7. Screen frame titles should be constructed using standard Title Case.
8. All emails generated from SAP programs should use proper grammar and punctuation and
appropriate line-wrapping.

DIALOG PROGRAM STANDARDS
1. Module Pool
a. Transactions are maintained using SAP transaction SE38 (ABAP Editor).
b. Naming convention – SAPMZXX_
c. Naming convention for includes

i. MZXX_...TOP – Global data
ii. MZXX_...O01 – PBO modules
iii. MZXX_...I01 – PAI modules
iv. MZXX_...F01 – Form routines
2. Screens
a. Transactions are maintained using SAP transaction SE51 (Screen Painter).
3. GUI Status
a. Standard menu bar, application toolbar and standard toolbar are maintained using
SAP transaction SE41 (Menu Painter).
4. Miscellaneous
a. Initialize all screen fields and global variables in the PBO (Process before Output)
module.
b. PAI (Process after Input) should contain the logic to be executed after the user has
selected a function key, menu item, etc.
c. POV (Process on Value-Request) should contain logic to display list of possible

values on F4 request.
d. POH (Process on Help-Request) should contain logic to display help information on

F1 request.

TRANSACTION STANDARDS
Transactions are maintained using SAP transaction SE93 (Maintain Transactions).
User must select the appropriate “Start object“ on the first “Transaction Creation Screen”.
Depending on the underlying associated object (e.g.: Reports or Dialog Programs) user
selects the appropriate Start object type.
Figure 1
The following two sections describe the Transaction standards for Start object: Reports and
Dialog Programs respectively:
1. Reports
a. Transaction Code name can be up to 20 characters. The standard naming
convention (ZXX_) should be used (see Naming Standards).
b. The standard package is always ZDEV for UM clients only.
c. GUI Support – select all (HTML, Java, and Windows).


Figure 2
2. Dialog Programs
a. Transaction Code name can be up to 20 characters. The standard naming

convention (ZXX_) should be used (see Naming Standards).
b. The standard package is always ZDEV for UM clients only.
c. GUI Support – select all (HTML, Java, and Windows).


Figure 3


CODING STANDARDS
1. Formatting
a. Standardize formatting should be used to format all programs, function modules, etc.
To setup, select ‘Setting’ under the ‘Utilities’ option on the SAP toolbar. Select
‘ABAP Editor’ option. Within this option, select ‘Pretty Printer’. Check the
following options:
i. Indent
ii. Convert Uppercase/lowercase
iii. Keyword Uppercase
Figure 4

2. One command per line

a. Each ABAP/4 command consists of a sentence ending with a period. As a standard,
start each new command on a new line. This will allow for easier deleting,
commenting, and debugging.
3. Indented source code
a. For command statements that have a corresponding “END” (such as IF…ENDIF,
SELECT…ENDSELECT, LOOP…ENDLOOP), the “END” part of the statement
should be placed in the same column as the beginning part of the statement. It is
helpful to also comment the “END” statement by using the “ parameter on the same
line. For example,
LOOP at ITAB.
…….. statements here
ENDLOOP “ ITAB table
4. Variable naming
a. ABAP/4 variable names can be up to 30 characters for DATA fields and subroutines
and up to 8 characters for SELECT-OPTIONS and PARAMETERS, therefore, as a
standard, make the names descriptive. Do NOT use a hyphen “-“ in variable names
or in paragraph (“form”) names. Use the underscore “_” instead. SAP uses the
hyphen “-“ to separate a table name from the name of a field in that table. Using an
underscore will increase readability of your program.
b. Some variable types should be prefixed with a specified letter or letters:

Variable Type Prefix
Selection screen parameter p_ or a_
Form routing parameter p_
Select-options s_
Ranges r_
Internal tables (global) t_ or gt_
Internal tables (local) lt_
Local structures ls_
Global structures gs_
Constants c_ or lc
Global constants gc_
Local variables lv_
Global variables gv_
c. Whenever possible, the LIKE parameter should be used to define the type of a
variable.
d. Whenever possible, global constants should be used instead of creating local

constants or hard-coded values. For function modules and dialog programs, global

constants should be stored in the “MZXX_...TOP” section of the function module

group.
5. Reusable code
a. If a block of code is executed more than once, it should be placed in a subroutine at
the bottom of the code or in a function module. This makes the code more readable,
requires less indentation, and is easier to debug.
6. Parameter passing in subroutine
a. Whenever possible use a TYPE or LIKE statement when specifying the formal
parameters of a subroutine. This is a good programming style, plus it allows the
ABAP compiler to generate more efficient code (which can increase performance up
to a factor of 2x).
7. Text handling
a. Variable names should not be used on the parameter selection screen for any
program placed in production. Use the “Text Element” function found in the ABAP
editor to describe the selection criteria and relate it to the variable name.
b. INCLUDE files can't define their own Text Elements - any Text Elements to which
they refer must be defined in the main program which invokes the INCLUDE file.
TIP: You can use the INITIALIZATION event of the “include” program to set the
values of these text elements.
8. Usage of UserIDs in programs
a. In no case should a production program or function contain a UserID as either literal
or constant data. In the development system it may be necessary to code temporary
breakpoints for specific UserIDs, however, these debugging techniques must be
removed before the program is transported.
9. Messages
a. Declare the message class in the report statement. While it is possible to specify the
message class each time a message is output, it is easier to specify once it in the
report statement. You can still use a message from another class than the one
defined in the report by adding the class in parentheses after the message. Messages
can be defined using SAP transaction SE91 (Message Maintenance: Initial Screen).
b. Messages should use proper grammar and punctuation.
10. Development Class
a. The development class of any program, table, function, etc., should be ZDEV for
UM clients only. If a special development class is required, authorization must be
request from BASIS (see Authorization Standards for more information).

11. Source Code Documentation

a. It is wise to provide future programmers with documentation inside your source
code. Explain the purpose, design, structure and any testing hints at the top of the
program.
b. All programs should also have a modification log displayed at the top of the
program. This log should the initials of the developer making the change, the date
of the change, and a description of the change. The log should be dated with the
most recent change first. For example:
Figure 5
c. Comment work fields, and fields in work records especially those used for
interfacing. Comments should explain what the code is doing.
d. Comments should be included before each “form” subroutine to briefly describe

what the subroutine is to accomplish. Comments should also be placed before SAP
events. These comments help to pinpoint the beginning of events and subroutines,
and help direct the flow of logic.

Figure 6
Figure 7
e. It is also helpful to include comments for each block of code designed to accomplish
a task. For example:
Figure 8
12. Function Modules

a. The standard naming convention (ZXX_) should be used for naming Function
Modules and Function Groups (see Naming Standards).

b. The import and export parameters of function modules should be documented at the
top of the source code section of the function module with brief descriptions of the
fields and their typical contents. Also, any special requirements or usage should be
noted.
c. The first letter of the parameter’s name should indicate the direction in which the
parameter was passed:
Input or importing = I
Output or exporting = E
Bi-directional or changing = C
d. The second letter of the parameter’s name should indicate the nature of the formal
parameter:
Single value or variable = V
Single structure or record (however complicated) = S
Internal table (however complicated the line structure) = T
e. Function modules that contain database reads should also contain at least one
EXCEPTION parameter.
f. All RFCs (Remote Function Call) must contain at least one EXCEPTION parameter.

PERFORMANCE STANDARDS
1. General Performance Standards
a. "Dead" code - (Avoid leaving "dead" code in the program. Comment out (or delete)
variables that are not referenced and code that is not executed. Use program -->
check --> extended program to check to see a list of variables which are not
referenced statically.
Figure 9
b. Logical databases - Most SAP modules have logical databases that are available for
your use. However, it has been found that unless you are using a lot of the data from
the logical databases, the runtime of the program using a logical database is greatly
increased from one directly accessing a database table using a “SELECT” statement.
c. Subroutine usage - For good modularization, the decision of whether or not to

execute a subroutine should be made before the subroutine is called. For example:
This is better:
IF f1 NE 0.
PERFORM sub1.
ENDIF.
FORM sub1.
...
ENDFORM.
Than this:
PERFORM sub1.
FORM sub1.

IF f1 NE 0.
...
ENDIF.
ENDFORM.
d. IF statements - When coding IF tests, nest the testing conditions so that the outer
conditions are those which are most likely to fail. For logical expressions with AND,
place the mostly likely false first and for the OR, place the mostly likely true first.
e. CASE vs. nested Ifs - When testing fields "equal to" something, one can use either
the nested IF or the CASE statement. The CASE is generally better because it is
easier to read.
f. MOVE-ing structures - When records a and b have the exact same structure, it is
more efficient to MOVE a TO b than to MOVE-CORRESPONDING a TO b.
g. SELECT – Direct SELECT statements should only be used if the data can not be
accessed using a function module or an evaluation path. When possible the
SELECT statements should be stored in a function module.
h. SELECT and SELECT SINGLE - When using the SELECT statement, study the
key and always provide as much of the left-most part of the key as possible. If the
entire key can be qualified, code a SELECT SINGLE not just a SELECT. If you
are only interested in the first row or there is only one row to be returned, using
SELECT SINGLE can increase performance by up to 3x.
i. Check each SELECT statement for the use of index. This can be most easily
determined using the Code Inspector, transaction SCI, which will report on any
SELECT statement against large tables not using an index.
j. Check that there is no assumed sort order after the SELECT statement. Do not
assume that the data will be returned in primary key order.
k. SELECT * versus SELECTing individual fields - In general, use a SELECT

statement specifying a list of fields instead of a SELECT * to reduce network traffic
and improve performance. For tables with only a few fields the improvements may
be minor, but many SAP tables contain more than 50 fields when the program needs
only a few. In the latter case, the performance gains can be substantial.
l. SELECT – Direct SELECT statements should only be used if the data can not be
accessed using a function module or an evaluation path. When possible the
SELECT statements should be stored in a function module.
m. Small internal tables vs. complete internal tables - In general it is better to minimize
the number of fields declared in an internal table. While it may be convenient to

declare an internal table using the LIKE command, in most cases, programs will not
use all fields in the SAP standard table.
n. Refreshing internal tables – When you are done working with an internal table
REFRESH the table to release it from memory.
o. Row-level processing of a table - Selecting data into an internal table using an array
fetch versus a SELECT-ENDELECT loop will give at least a 2x performance
improvement. After the data has been put into the internal data, then row-level
processing can be done. For example, use:
select ... from table <..>
into <itab> (corresponding fields of itab)
where ...
loop at <itab>
<do the row-level processing here>
endloop.
instead of using:
select ... from table <..>

where ...
<row-level processing>
append <itab>.
endselect.
p. READing single records of internal tables – When reading a single record in an

internal table, the READ TABLE WITH KEY is not a direct READ. This means
that if the data is not sorted according to the key, the system must sequentially read
the table. Therefore, you should SORT the table and use READ TABLE WITH
KEY BINARY SEARCH for better performance.
q. SORTing internal tables - When SORTing internal tables, specify the fields to be
SORTed.
r. Deleting duplicates – After sorting internal tables, remember to use the command
“DELETE ADJACENT DUPLICATES FROM” to remove duplicate records.
s. Number of entries in an internal table - To find out how many entries are in an
internal table use DESCRIBE.
t. Length of a field - To find out the length of a field use the string length function.
LV_FLDLEN = STRLEN (FLD).

u. Nested SELECTs versus table views - Since OPEN SQL does not allow table joins,
often a nested SELECT loop will be used to accomplish the same concept.
However, the performance of nested SELECT loops is very poor in comparison to a
join. Hence, to improve performance by a factor of 25x and reduce network load,
you should create a view in the data dictionary, then use this view to select data.
v. If nested SELECTs must be used - As mentioned previously, performance can be

dramatically improved by using views instead of nested SELECTs, however, if this
is not possible, then the following example of using an internal table in a nested
SELECT can also improve performance by a factor of 5x:
Use this:
form select_good.
data: t_vbak like vbak occurs 0 with header line.
data: t_vbap like vbap occurs 0 with header line.
select * from vbak into table t_vbak up to 200 rows.
select * from vbap for all entries in t_vbak

where vbeln = t_vbak-vbeln.
...
endselect.
endform.
Instead of this:
form select_bad.
select * from vbak up to 200 rows.
select * from vbap where vbeln = vbak-vbeln.
...
endselect.
endselect.
endform.
w. Avoid unnecessary statements - There are a few cases where one command is better
than two. For example:
Use:
append <tab_wa> to <tab>.
Instead of:
<tab> = <tab_wa>.
append <tab> (modify <tab>).
And also, use:
if not <tab>[] is initial.
Instead of:
describe table <tab> lines <line_counter>.
if <line_counter> > 0.
x. Copying or appending internal tables ⎯ Use this:

<tab2>[] = <tab1>[]. (if <tab2> is empty)
Instead of this:
loop at <tab1>.
append <tab1> to <tab2>.

endloop.
y. Clear vs Refresh – Use the CLEAR statement to initialize local variables and local
structures. Use the REFRESH statement to initialize local tables. If the table has a
header row, use “REFRESH lt_table[]” to clear both the table and the header row.
Don’t forget to re-initialize local variable and table before each re-use.
z. Report display – Make sure the case matches throughout the report. Do not mix all
upper-case displays with all lower-case displays. Ex:
Do not display:
SHIELA LONG, academic administrator, school of education
Instead use:
Sheila Long, Academic Administrator, School of Education
aa. System fields – ABAP automatically stores information necessary to control the
program’s internal flow of logic in some system fields and tables. These fields and
tables are accessible by the programmer. It is better to use a system field than to
create logic to generate the same data (i.e. current time, current date, table index,
etc.). A list of system fields and system tables can be found in The Official ABAP
Reference
2. Performance Checking
a. Performance diagnosis ⎯ SAP transaction SE30 (ABAP/4 Runtime Analysis) must
be ran on all new programs before they are put into production. This utility allows
statistical analysis of transactions and programs.
b. Error checking – Use the SAP transaction SCI (Code Inspector) to spot meaningful
error; however, the developer will still need to use judgment to filter out
meaningless errors.

DICTIONARY: TABLE STANDARDS
1. User-developed table naming convention

a. Table names are limited to 16 characters. Follow the naming convention for
programs as far as the first 3 to 4 characters are concerned (ex. ZFPM, ZAM, ZFI).
2. User-developed table definition convention
a. The first field defined for any customer table should be: MANDT. This is the 'client'
field, and makes the table specific to the client that it is used/modified in.
b. Field names do not have to begin with ‘Z’; however, the field name should be
descriptive.
3. Maintenance settings
a. "Tab. Maint. Allowed" 'X' or (blank)
i. An 'X' indicates that this table is to be maintained directly using the
"Standard Table Maintenance" functions (SM31 / SM30). This means that
the table can be maintained independently of any other table or application.
This should only be used for tables that have a relatively low number of
updates, done on an infrequent basis. Tables that are maintained this way are
typically used to set control information, or similar table values that change
infrequently, but will change. Examples are tax rates, overhead rates,
program control tables, message tables, program or error status tables, etc.
ii. Tables maintained this way should NOT have any dependency on other
tables or other entries in the same table for the validity of a new entry or new
value, unless that dependency can be validated through the use of a check
table for the field.
iii. X should be selected ONLY if the table is to be maintained by the "Standard
Table Maintenance" functions. (SM30 or SM31) Any table for which entries
are maintained / changed / inserted / deleted by an application should in most
cases not have this field checked.
Updates: Direct database updates of SAP standard tables

Under no circumstances should any program directly update SAP-delivered tables using the
INSERT, UPDATE, or DELETE commands. SAP-delivered tables begin with all letters other than
Y and Z, and they should only be updated using an SAP transaction. To automate updates to SAP
tables via a program, you can use an SAP supplied function module.

RULES STANDARDS
1. Each University should have their own instance of programs ZGBBR000 and ZGBBS000, and
VSR.
2. Exit names (in ZGBBR000 or ZGBBS000)

a. Limited to 5 characters.
b. They should all begin with “U”.
Figure 10
3. Validations and Substitutions

b. Uses exit: same name as Exit
i. Info-only (footnote): IMSG001-IMSG999
Figure 11
c. Program-type related: Begin with 1st character of program-type

i. Uxxxxxx (UMAXHRS for Undergraduate Maximum Hours)
ii. Lxxxxxx (LMAXHRS for Law Maximum Hours)
iii. Gxxxxxx (GMINHRS for Graduate Minimum Hours)
Figure 12
d. School related: Begin with 1st three characters associated with school
i. LAxxxxx ( Liberal Arts)
ii. BUSxxxx (School of Business)

iii. ENGxxxx (School of Engineering)
Figure 13
e. Department related: Begin with Department/Course prefix

i. MLANGxx (Modern Languages)
ii. ENGL (English)
Figure 14
f. Classification related: Begin with classification prefix

i. FRxxxxx (Freshman)
ii. SOxxxxx (Sophomore)
iii. JRxxxxx (Junior)
iv. SRxxxxx (Senior)
Figure 15
g. Campus related: Begin with campus prefix

i. OXFxxxx (Oxford)
Figure 16
h. Status related: Begin with status prefix

i. HONxxxx (Honors)
Figure 17
i. Specialization related: Begin with X, then<specialization>

i. XMATHxx for Math Majors
Figure 18

4. Rule Modules
a. Limited to 4 numbers with desc.
b. All descriptions same as Validation or Substitution as referenced.
Figure 19
5. Rule Containter
b. In general, similar text as used in validation, but enhanced for Web display purposes.
i. PRxxxxxxxx for Pre-requisite
ii. COxxxxxxxx for Co-requisite
iii. SPECxxxxxx for Specialization
iv. IMSGxxxxx for Informational Message
Figure 20

TRANSPORTING STANDARDS
1. Communication
a. If you are going to working on a program, function module, table, structure, etc. for
a length of time, it is crucial that you communicate with the other developers before
transporting these items to production.
b. It is the developer’s responsibility to determine if a more recent copy of any item in

his/her transport group has already been moved to production.
2. Transports
a. Transports are requested using transaction ZTRANSPORT_FORM.
b. When transporting more than one transport group, be sure to transport the groups in
the order they were created.
c. When completing a project, transport ALL transport groups for that project into
production.
3. Re-imports
a. Re-import requests are submitted using the Transports transaction
ZTRANSPORT_FORM.
b. Requests for transports to be re-imported into QAS and PROD must be submitted in
PROD. Be sure to select the correct Target System.
c. If transports were not originally submitted in the correct order, they can be re-
submitted using the Reimport Request option.
d. When completing a project, transport ALL transport groups for that project into
production.
4. Critical Imports
a. Critical Import requests are submitted using the Transports transaction
ZTRANSPORT_FORM.
b. Requests for transports are generally done at set times during normal workdays.
Any requests for transports that need to be completed outside of these normally
scheduled times must be coded as Critical.
c. Only transports that are truly crucial to the operating of the system should be marked
as Critical.

d. Developers must enter an explanation for the critical transport in the “Requester’s
Comments for BASIS / Reason for Critical Transport”.
Figure 21

TESTING STANDARDS
1. Internal testing
a. All projects (including enhancements) should be tested internally within IT before
being reviewed by the requestor. Appropriate support teams in IT are available to
assist with this task.
b. All developers are responsible for developing their own test plans. Test plans
should include an appropriate sampling of data before and after project has ran.
They should also include measure to ensure the appropriate outcome.
c. A program review will be conducted by the appropriate manager.

2. Return Codes
a. Test all return codes (sy-subrc) for success and failure after any I/O and calls to
function modules (database selects, internal table reads, call transaction, etc.)
3. Performance analysis
a. Program performance analysis should be conducted using SE30 (ABAP Runtime
Analysis) .
4. Requestor Review
a. All projects should be tested/reviewed and signed-off on by the requestor before
they are moved to production.

AUTHORIZATIONS STANDARDS
The SAP authorization concept protects transactions, programs, and services in SAP
systems from unauthorized access. On the basis of the authorization concept, the administrator
assigns authorizations to the users that determine which actions a user can execute in the SAP
System after he or she has logged on to the system and authenticated himself or herself. Follow
standards to restrict access for any table, program, transaction or service.
a. The development class of any restricted program, table, function, etc., should not be
ZDEV. Consult with BASIS and create a new package specific to application
having name starting with Z, and use this package as development class.
Figure 22
b. For Dictionary objects: select Utilities-> Assign Authorization Group and enter
table/view name associated with newly created package name as Authorization
Group.
Figure 23
c. Submit a request with BASIS to link authorization object related to this new
package and restrict the access.

PROJECT LIFE CYCLE

Figure 24
1. Project request arrives via IT Work Request.
2. CIO approves/disapproves project
3. Approved projects
a. Written Requirements
i. IT and requestors develops and agree on written requirements.
ii. Requestor must sign-off on requirements before development on the project
can begin.
b. Design Document and Project Schedule
i. The Developer/Project Team will be responsible for creating a design
document and project schedule.

ii. The Director or Associate Director of Enterprise Applications must sign-off

on the design document.
iii. More complex projects will require a sign-off by the CIO/Deputy CIO also.
c. Project Development
i. Developer/Project Team will be responsible for developing code,
configuring the system, creating interfaces, etc. as needed for the project.
ii. Weekly/Bi-weekly checkpoints should be setup to monitor the progress of
the project.
iii. All development should take place in the development/test system.
d. Internally Testing
i. Project should be tested within IT first.
ii. Appropriate support teams within IT will be available to assist with testing,
such as, SAP Support Team, FTDC, Helpdesk, and Academic Computing
Coordinator. The developer is responsible for ensuring an appropriate
test plan has been developed.
iii. Problems during internal testing should be fixed before the project moves to
the next step.
e. Requestor Testing
i. Once project has been tested internally, the project should be tested/reviewed
by the requestor.
ii. The developer should assist the requestor in developing an adequate test
plan.
f. Finalization
i. Support teams will be responsible for finalizing documentation and for
developing a roll-out plan.
ii. Support teams will be responsible for conducting necessary user training to
support the project.
iii. The developer will be responsible for coordinating efforts with BASIS to
ensure appropriate user authorizations have been granted.
g. Deployment
i. Projects are not to be deployed to the production system(s) until the
requestor has signed-off.
ii. The developer will be responsible for making sure all transports related to
the project are properly deployed.
h. Notification
i. The developer will be responsible for notifying the requestor when the new
functionality will be available.
ii. The developer will be responsible for determining if others on campus need
to be aware of the new function (i.e. appearance of a new tab on Student
File).
4. Disapproved projects
a. CIO/Director of Enterprise Application notifies requestor.

REFERENCES
1. The SAP Style Guide is available in the help documentation using the following path:
a. Help -> R/3 Library -> BC-Basis Components -> ABAP Workbench (BC-DWB) ->
BC-> SAP Style Guide.
2. The task code ABAPDOCU or ABAPHELP can be accessed through the command
window.
3. Inside the ABAP editor, you can click on the “Information” or “I” icon.

UM ABAP Development Standards Guide

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

UM ABAP Development Standards Guide

Transféré par

Droits d'auteur :

Formats disponibles

2008

NAMING STANDARDS ................................................................................................................... 4

The University of Mississippi | Confidential

3. Performance analysis ............................................................................................................ 27

The University of Mississippi | Confidential

SAP Development Standards Guide

b. XX — where XX is the SAP module. Current SAP modules include:

e. The remaining 31-36 characters may be as descriptive as you wish.

The University of Mississippi | Confidential

5. Event paragraphs should be listed in a logical order inside of a START-OF-SELECTION

7. Screen frame titles should be constructed using standard Title Case.

The University of Mississippi | Confidential

b. Naming convention – SAPMZXX_

c. Naming convention for includes

c. POV (Process on Value-Request) should contain logic to display list of possible

d. POH (Process on Help-Request) should contain logic to display help information on

The University of Mississippi | Confidential

b. The standard package is always ZDEV for UM clients only.

c. GUI Support – select all (HTML, Java, and Windows).

The University of Mississippi | Confidential

a. Transaction Code name can be up to 20 characters. The standard naming

b. The standard package is always ZDEV for UM clients only.

c. GUI Support – select all (HTML, Java, and Windows).

The University of Mississippi | Confidential

The University of Mississippi | Confidential

The University of Mississippi | Confidential

2. One command per line

b. Some variable types should be prefixed with a specified letter or letters:

d. Whenever possible, global constants should be used instead of creating local

The University of Mississippi | Confidential

constants should be stored in the “MZXX_...TOP” section of the function module

The University of Mississippi | Confidential

11. Source Code Documentation

d. Comments should be included before each “form” subroutine to briefly describe

The University of Mississippi | Confidential

12. Function Modules

The University of Mississippi | Confidential

The University of Mississippi | Confidential

c. Subroutine usage - For good modularization, the decision of whether or not to

k. SELECT * versus SELECTing individual fields - In general, use a SELECT

The University of Mississippi | Confidential

select ... from table <..>

p. READing single records of internal tables – When reading a single record in an

The University of Mississippi | Confidential

v. If nested SELECTs must be used - As mentioned previously, performance can be

select * from vbak into table t_vbak up to 200 rows.

select * from vbap for all entries in t_vbak

x. Copying or appending internal tables ⎯ Use this:

The University of Mississippi | Confidential

The University of Mississippi | Confidential

1. User-developed table naming convention

Updates: Direct database updates of SAP standard tables

The University of Mississippi | Confidential

2. Exit names (in ZGBBR000 or ZGBBS000)

3. Validations and Substitutions

c. Program-type related: Begin with 1st character of program-type

iii. ENGxxxx (School of Engineering)

e. Department related: Begin with Department/Course prefix

f. Classification related: Begin with classification prefix

g. Campus related: Begin with campus prefix

h. Status related: Begin with status prefix

i. Specialization related: Begin with X, then<specialization>