sitemap
| SapMaterial.com |
 | |  | |  | |  | |  | |  | |  | |  | |  |
SAP ABAP DEVELOPMENT STANDARDS - page2
AUTHORIZATIONS (1.9)
Z TABLE AUTHORIZATION GROUPS
Table authorizations should be taken into account when creating new Z tables.
For tables maintained via SM30, authorization groups ARE required whether or not the table contains sensitive information.
Different authorization groups may also be also required depending on the action performed on the table i.e. view, update, etc.. One
word of caution when grouping tables together; since table accesses are granted at the authorization group level, depending on the
authorization group assigned to a user profile, a user will get access to ALL tables in the authorization group.
For tables maintained via an update program, authorization groups are NOT required. Access to these tables will be controlled via
the transaction codes assigned in the update program.
Developers are responsible to provide the table authorization group name while Basis-Security is responsible to create the group on
the development machine and to assign the group to each table in the group. This can be done via transaction code SM31 on table
TDDAT which will generate 2 transports (one for the creation of the authorization group and one for the assignment of the tables to
the authorization group). DO NOT FORGET TO ADVISE BASIS-SECURITY TO INCLUDE THOSE 2 TRANSPORTS, IN THE
SEQUENCE THEY WERE CREATED, WHEN PROMOTING TO QA AND PROD.
Z table authorization groups, when required, should adhere to the following naming conventions:
Z TABLE AUTHORIZATION GROUPS
Table authorizations should be taken into account when creating new Z tables.
For tables maintained via SM30, authorization groups ARE required whether or not the table contains sensitive information.
Different authorization groups may also be also required depending on the action performed on the table i.e. view, update, etc.. One
word of caution when grouping tables together; since table accesses are granted at the authorization group level, depending on the
authorization group assigned to a user profile, a user will get access to ALL tables in the authorization group.
For tables maintained via an update program, authorization groups are NOT required. Access to these tables will be controlled via
the transaction codes assigned in the update program.
Developers are responsible to provide the table authorization group name while Basis-Security is responsible to create the group on
the development machine and to assign the group to each table in the group. This can be done via transaction code SM31 on table
TDDAT which will generate 2 transports (one for the creation of the authorization group and one for the assignment of the tables to
the authorization group). DO NOT FORGET TO ADVISE BASIS-SECURITY TO INCLUDE THOSE 2 TRANSPORTS, IN THE
SEQUENCE THEY WERE CREATED, WHEN PROMOTING TO QA AND PROD.
Z table authorization groups, when required, should adhere to the following naming conventions:
POSITION
1 ‘Z’ required by SAP;
2 Application Area (Ref. Appendix A);
3-4 2 digits assigned in sequence (e.g. ZK01, ZK02).
Z PROGRAM AUTHORIZATION GROUPS
Program authorizations, which check a user’s authority to execute a certain program, should be taken into account when
creating new Z programs.
For report programs included in the generic reporting tree, authorization groups ARE required IF AND ONLY IF the report
contains sensitive information. By default, SAP reports in the generic reporting tree are not assigned to any authorization
group and their security is controlled at the transaction code level of the generic reporting tree (i.e. SRET). Any new Z report
programs added to the generic reporting tree will adhere to the same standard. However, reports containing sensitive
information need to be further protected against general access and this will be done through the use of authorization groups .
For these programs, the authorization group should be created and/or maintained by executing program RSCSAUTH (Report
Authorization Maintenance). This will eliminate the need to change the program attributes while allowing to restore customer-
specific authorization groups following an upgrade.
For programs assigned to a transaction code (please refer to section 1.4 for more information), authorization groups are NOT
required. Access to these programs will be controlled via the transaction code assigned to the program.
For BDC programs, authorization groups are NOT required. Since these programs are only run in batch and since access to
SA38/SE38 should not be granted in production, it is safe not to assign authorization group to BDC programs. On the other
hand, the BDC error correction process will be secured via transaction code SM35 which will be associated to specific BDC
session names.
When setting authorization groups using the program attributes, it is the developer’s responsibility to provide the program
authorization group name while Basis-Security is responsible to create the group in table TPGP via transaction code SE16. And
since SE16 does NOT generate any transport requests, the Transport Request Form must include, under Exception Processing,
that these program authorization groups must be created on the QA and the PROD machines prior to processing the other
transport requests.
POSITION
1 ‘Z’ required by SAP;
2 Application Area (Ref. Appendix A);
3-8 Descriptive name for the group.
PRINT SPOOL AUTHORIZATION
Print spools which contain sensitive information (e.g. payroll data) should be protected by setting the authorization field in the
print specifications of the job. Only users with this authorization in their profiles will be allowed to display the print spool.
Print spool authorization, when required, should adhere to the following naming conventions
Program authorizations, which check a user’s authority to execute a certain program, should be taken into account when
creating new Z programs.
For report programs included in the generic reporting tree, authorization groups ARE required IF AND ONLY IF the report
contains sensitive information. By default, SAP reports in the generic reporting tree are not assigned to any authorization
group and their security is controlled at the transaction code level of the generic reporting tree (i.e. SRET). Any new Z report
programs added to the generic reporting tree will adhere to the same standard. However, reports containing sensitive
information need to be further protected against general access and this will be done through the use of authorization groups .
For these programs, the authorization group should be created and/or maintained by executing program RSCSAUTH (Report
Authorization Maintenance). This will eliminate the need to change the program attributes while allowing to restore customer-
specific authorization groups following an upgrade.
For programs assigned to a transaction code (please refer to section 1.4 for more information), authorization groups are NOT
required. Access to these programs will be controlled via the transaction code assigned to the program.
For BDC programs, authorization groups are NOT required. Since these programs are only run in batch and since access to
SA38/SE38 should not be granted in production, it is safe not to assign authorization group to BDC programs. On the other
hand, the BDC error correction process will be secured via transaction code SM35 which will be associated to specific BDC
session names.
When setting authorization groups using the program attributes, it is the developer’s responsibility to provide the program
authorization group name while Basis-Security is responsible to create the group in table TPGP via transaction code SE16. And
since SE16 does NOT generate any transport requests, the Transport Request Form must include, under Exception Processing,
that these program authorization groups must be created on the QA and the PROD machines prior to processing the other
transport requests.
POSITION
1 ‘Z’ required by SAP;
2 Application Area (Ref. Appendix A);
3-8 Descriptive name for the group.
PRINT SPOOL AUTHORIZATION
Print spools which contain sensitive information (e.g. payroll data) should be protected by setting the authorization field in the
print specifications of the job. Only users with this authorization in their profiles will be allowed to display the print spool.
Print spool authorization, when required, should adhere to the following naming conventions
ABAP/4 STANDARDS CONVENTIONS
General Standards (2.0)
· ABAP programs that update master and transactional data MUST ALWAYS use SAP transaction codes (where transaction codes are available) by utilizing BDC or
‘call transaction’ utilities. The only exception to this would be the use of a BAPI or "direct input" program provided by SAP. These methods ensure that logical units of
work, rollback, locking operations and edits are performed. SAP-supplied tables MUST NEVER be updated directly by custom programs.
· ABAP programs MUST NEVER be used to update configuration tables.
· SAP-delivered ABAP programs, Dynpros, SAP transactions and Batch programs should never be changed without the approval of the Development Team Leader.
SAP approval will also generally be required. If it becomes necessary to modify one of these objects, then, if possible, the object should be copied to a new name using
SAP naming standards, and modifications should be made to the copied object.
· Before writing any code, make sure that no existing programs or function modules, either custom or SAP-supplied, satisfy the coding requirements.
· If custom coding is necessary, attempt to write the module so that it is re-usable and can be stored in a central library. Function modules are an example of this
approach.
PROGRAM ATTRIBUTES (2.1)
Even though it is not mentioned in section 2.1 of the SAP standards, a title MUST be set in the program attributes.
In addition, “Authorization group” should NOT always be left blank as suggested in the SAP standards. Please refer to section 1.9 - sub-section Z program authorization
groups - for more information on when authorization groups are required.
PROGRAM INTERNAL STRUCTURES (2.2)
Since the naming conventions suggested by SAP are very strict while not adding much in the area of facilitating the maintenance, these naming conventions can be
followed but will not be enforced.
PROGRAM VARIABLE NAMES (2.3)
Since the naming conventions suggested by SAP are very strict while not adding much in the area of facilitating the maintenance, these naming conventions can be
followed but will not be enforced.
VARIANTS (2.8)
Since variants are attached to a program, there is no need for the strict naming conventions suggested by SAP. As such, no need for the Z for the program name which
leaves us with 11 characters for a logically meaningful name.
General Standards (2.0)
· ABAP programs that update master and transactional data MUST ALWAYS use SAP transaction codes (where transaction codes are available) by utilizing BDC or
‘call transaction’ utilities. The only exception to this would be the use of a BAPI or "direct input" program provided by SAP. These methods ensure that logical units of
work, rollback, locking operations and edits are performed. SAP-supplied tables MUST NEVER be updated directly by custom programs.
· ABAP programs MUST NEVER be used to update configuration tables.
· SAP-delivered ABAP programs, Dynpros, SAP transactions and Batch programs should never be changed without the approval of the Development Team Leader.
SAP approval will also generally be required. If it becomes necessary to modify one of these objects, then, if possible, the object should be copied to a new name using
SAP naming standards, and modifications should be made to the copied object.
· Before writing any code, make sure that no existing programs or function modules, either custom or SAP-supplied, satisfy the coding requirements.
· If custom coding is necessary, attempt to write the module so that it is re-usable and can be stored in a central library. Function modules are an example of this
approach.
PROGRAM ATTRIBUTES (2.1)
Even though it is not mentioned in section 2.1 of the SAP standards, a title MUST be set in the program attributes.
In addition, “Authorization group” should NOT always be left blank as suggested in the SAP standards. Please refer to section 1.9 - sub-section Z program authorization
groups - for more information on when authorization groups are required.
PROGRAM INTERNAL STRUCTURES (2.2)
Since the naming conventions suggested by SAP are very strict while not adding much in the area of facilitating the maintenance, these naming conventions can be
followed but will not be enforced.
PROGRAM VARIABLE NAMES (2.3)
Since the naming conventions suggested by SAP are very strict while not adding much in the area of facilitating the maintenance, these naming conventions can be
followed but will not be enforced.
VARIANTS (2.8)
Since variants are attached to a program, there is no need for the strict naming conventions suggested by SAP. As such, no need for the Z for the program name which
leaves us with 11 characters for a logically meaningful name.
POSITION
1-11 Meaningful name for the variant.
ABAP/4 PROGRAMMING STANDARDS and PRACTICES
PROGRAM STRUCTURE (3.1)
Program structure does not need to be as restrictive as what is suggested by SAP however you should at least ensure that your program structure follows this
sequence:
· Report Statement
· Main documentation block
· Data declarations
· Tables
· I/O parameters (incl. select options, parameters and ranges)
· Working variables
· Mainline logic (which includes all events)
· Subroutines
NOTE: It may sometimes be a real time-saver to create a new program by copying an existing one which is either very well structured and/or which contain similar
functionality to the one required. HOWEVER…, if you do so, ensure that the ABAP title of the new program is at least different from the program that it was copied
from. In addition, all program attributes and text elements should be reviewed to ensure that the new program does not carry incorrect attributes and/or text elements
when promoted to production.
MAIN DOCUMENTATION BLOCK (3.2)
PROGRAMS should include a main documentation block at the top. This block should give the program name, its purpose as well as a list of the external files it
processes. It should also include a business description of the interface files and, for files which are parameter driven, the source/destination directory of the file. Please
refer to Appendix G, which replaces Appendix G defined in the ABAP/4 Naming Conventions, for an example.
MODULE POOLS should contain the exact same information as programs but only the main module should be documented and NOT the individual online includes.
BATCH AND SHARED INCLUDES should contain similar information as programs with the exception of external files and RFC enabled. Please refer to Appendix G
for an example.
FUNCTION MODULES should also contain the same information but with an additional line to identify if the function module is RFC enabled or not.
SUBROUTINES/FORMS should complete the standard SAP documentation box that SAP provides when inserting a form.
The End
All of the product names here are trademarks of their respective companies. The site www.allsaplinks.com no way affiliated with
SAP AG. We have made every effort for the content integrity. Information used on this site is at your own risk.
SAP AG. We have made every effort for the content integrity. Information used on this site is at your own risk.
ABAP TECHNICAL
SAP Introduction
sap abap faq
sap Tables
SAP Transaction codes
Internal tables
data dictionary
performance tuning
transports & Requests
Sap scripts
Smartforms
lsmw
reports
sap Workflow
module pool/ dialog
programming
table control
user exits
sap memory
abap memory
alv reports
ABAP ADVANCED
IDOC
ALE
BAPI
BADI
RFC
FUNCTIONAL SIDE
Materials Management
FICO
Human Resources
BIW / BW / SEM
Free Documentation
Abap Material
Ale Material
BAPI Material
BC Material
IDOC Material
R/3 Database Management
SAP material
RFC
Transport
Sales & Distribution Material
Basic Data and Function
Material
Basis (BC) Material
Billing Material
CA Material
CATT : Computer Aided Test
Tool
Capacity Evaluation and
leveling Material
Capacity Planning Material
Cross Application Material
Countries
Customer Service Material
Enterpise Material
Financial / Controlling (FICO)
Internet Time Sheet
Inspection Material
HR Material
Material Management
Material
Payments Material
Payroll Material
Pension Fund
Production Planning and
Control
Plant Maintenance
Quality Management Material
Real Estate Material
SAP material
Wage Types
SAP Introduction
sap abap faq
sap Tables
SAP Transaction codes
Internal tables
data dictionary
performance tuning
transports & Requests
Sap scripts
Smartforms
lsmw
reports
sap Workflow
module pool/ dialog
programming
table control
user exits
sap memory
abap memory
alv reports
ABAP ADVANCED
IDOC
ALE
BAPI
BADI
RFC
FUNCTIONAL SIDE
Materials Management
FICO
Human Resources
BIW / BW / SEM
Free Documentation
Abap Material
Ale Material
BAPI Material
BC Material
IDOC Material
R/3 Database Management
SAP material
RFC
Transport
Sales & Distribution Material
Basic Data and Function
Material
Basis (BC) Material
Billing Material
CA Material
CATT : Computer Aided Test
Tool
Capacity Evaluation and
leveling Material
Capacity Planning Material
Cross Application Material
Countries
Customer Service Material
Enterpise Material
Financial / Controlling (FICO)
Internet Time Sheet
Inspection Material
HR Material
Material Management
Material
Payments Material
Payroll Material
Pension Fund
Production Planning and
Control
Plant Maintenance
Quality Management Material
Real Estate Material
SAP material
Wage Types