ibm development standards and guidelines - draft 2

Supply Chain Transformation

Development Standards and Guidelines

for

VERIZON Supply Chain Transformation Project

Verizon Proprietary/Confidential of 60


TABLE OF CONTENTS

1.0 Overview................................................................................................................................................................... 52.0 Programming Standards Definitions....................................................................................................................... 53.0 Development Methodology...................................................................................................................................... 64.0 Development Guidelines.......................................................................................................................................... 75.0 Program Structure.................................................................................................................................................... 96.0 External ABAP/4 Program Elements...................................................................................................................... 9

6.1 Selecting a Program Name................................................................................................................................. 96.2 Text Elements....................................................................................................................................................... 96.3 Attributes............................................................................................................................................................... 9

7.0 Internal ABAP/4 Program Elements..................................................................................................................... 127.1 Documentation Box............................................................................................................................................ 127.2 Declarative Elements......................................................................................................................................... 137.3 Event Elements.................................................................................................................................................. 177.4 Control Events.................................................................................................................................................... 187.5 Operation Events................................................................................................................................................ 23

8.0 Program Comments............................................................................................................................................... 248.1 Internal Programming comments...................................................................................................................... 248.2 External Programming comments..................................................................................................................... 25

9.0 ABAP/4 Coding Techniques.................................................................................................................................. 269.1 Data Selection.................................................................................................................................................... 269.2 Program Identifiers, Constants and Variables..................................................................................................279.3 Flags.................................................................................................................................................................... 279.4 PFKEYS Usage.................................................................................................................................................. 279.5 Screen Painter Standards.................................................................................................................................. 28

10.0 Reviews................................................................................................................................................................ 3010.1 Requirement and Design Reviews.................................................................................................................. 3010.2 Code Reviews................................................................................................................................................... 30

11.0 SAP Naming Conventions................................................................................................................................... 3211.1 Program Naming.............................................................................................................................................. 33

11.1.1 Local Private Programs............................................................................................................................. 3311.1.2 Production Programs................................................................................................................................ 33

11.2 Data Element.................................................................................................................................................... 3311.3 Domain.............................................................................................................................................................. 3411.4 Enhancement.................................................................................................................................................... 3411.5 Enhancement project....................................................................................................................................... 3411.6 Function Routines............................................................................................................................................ 34

11.6.1 Function Groups........................................................................................................................................ 3411.6.2 Function Modules...................................................................................................................................... 34

11.7 IDocs................................................................................................................................................................. 3511.7.1 IDoc Type................................................................................................................................................... 3511.7.2 IDoc Message............................................................................................................................................ 3511.7.3 IDoc Function Module............................................................................................................................... 35

11.8 Lock Object....................................................................................................................................................... 3611.9 Logical Database.............................................................................................................................................. 3611.10 Menu............................................................................................................................................................... 3611.11 Message......................................................................................................................................................... 36

11.11.1 Message ID.............................................................................................................................................. 36



11.11.2 Message number..................................................................................................................................... 3611.12 Module Pools.................................................................................................................................................. 3711.13 SAPscript........................................................................................................................................................ 3711.14 Standard Text ID............................................................................................................................................ 3811.15 Standard Text Name ----................................................................................................................................ 3811.16 SmartForms.................................................................................................................................................... 3811.17 Screens........................................................................................................................................................... 3811.18 Search Helps.................................................................................................................................................. 3911.19 SPA/GPA Parameter..................................................................................................................................... 3911.20 Tables............................................................................................................................................................. 39

11.20.1 Transparent Tables................................................................................................................................. 4011.20.2 Pooled tables and Cluster tables...........................................................................................................40

11.21 Transaction Codes......................................................................................................................................... 4011.22 Views............................................................................................................................................................... 40

11.22.1 Database view, Projection view, Maintenance view.............................................................................4011.22.2 Help view................................................................................................................................................. 41

11.23 Variants........................................................................................................................................................... 4111.24 BDC Sessions................................................................................................................................................ 4111.25 File Names...................................................................................................................................................... 4111.26 Classes........................................................................................................................................................... 4211.27 ABAP Objects................................................................................................................................................. 4211.28 Business Objects........................................................................................................................................... 4311.29 Workflow Templates...................................................................................................................................... 4411.30 Workflow Tasks.............................................................................................................................................. 44

12.0 Business Warehouse (BW)................................................................................................................................. 4512.1 Infocube............................................................................................................................................................ 4512.2 ODS Object...................................................................................................................................................... 4612.3 InfoSource........................................................................................................................................................ 4712.4 InfoObject......................................................................................................................................................... 4712.5 Query................................................................................................................................................................ 4712.6 InfoSet Query................................................................................................................................................... 4812.7 Roles................................................................................................................................................................. 4912.8 Restricted Key Figures.................................................................................................................................... 4912.9 Calculated Key Figures.................................................................................................................................... 5012.10 Variables......................................................................................................................................................... 5012.11 InfoPackage.................................................................................................................................................... 5112.12 InfoPackage Groups...................................................................................................................................... 5112.13 Periodic InfoPackage Jobs............................................................................................................................ 5212.14 Variants........................................................................................................................................................... 5312.15 Events............................................................................................................................................................. 5312.16 BW Query and Workbook Properties........................................................................................................... 54

13.0 Portals................................................................................................................................................................... 5513.1 iViews................................................................................................................................................................ 5513.2 Channels........................................................................................................................................................... 5613.3 Roles................................................................................................................................................................. 5613.4 Pages................................................................................................................................................................ 5613.5 Workset............................................................................................................................................................. 5713.6 External Services............................................................................................................................................. 5713.7 Folders.............................................................................................................................................................. 58

14.0 Logical Paths and Files........................................................................................................................................ 5815.0 Standard Header Routine.................................................................................................................................... 59



16.0 Change and Transport System........................................................................................................................... 6016.1 Overview........................................................................................................................................................... 6016.2 Creating a correction in the Development system.........................................................................................6016.3 Promotion of ETL jobs to QA or Production...................................................................................................60

17.0 WebLogic Integration (WLI) & Java Standards.................................................................................................6117.1 WLI Components Naming Standards............................................................................................................. 6117.2 WLI File Naming Standards............................................................................................................................. 6117.3 Java Source Files............................................................................................................................................. 62

17.3.1 Beginning Comments................................................................................................................................ 6217.3.2 Package and Import Statements.............................................................................................................. 6217.3.3 Class and Interface Declarations............................................................................................................. 6217.3.4 Comments.................................................................................................................................................. 6517.3.5 Block Comments....................................................................................................................................... 6517.3.6 Single-Line Comments.............................................................................................................................. 6517.3.7 Trailing Comments.................................................................................................................................... 6617.3.8 End-Of-Line Comments............................................................................................................................ 6617.3.9 Documentation Comments....................................................................................................................... 6617.3.10 Declarations............................................................................................................................................. 6817.3.11 Statements............................................................................................................................................... 6917.3.12 White Space............................................................................................................................................ 71

17.4 Naming Conventions........................................................................................................................................ 7217.5 Programming Practices................................................................................................................................... 7417.6 Code Examples................................................................................................................................................ 7517.7 Naming Conventions for Enterprise Applications...........................................................................................7617.8 Rules for Naming Conventions........................................................................................................................ 8017.9 XML Standards for EAI.................................................................................................................................... 8117.10 Java support for XML..................................................................................................................................... 81

17.10.1 Two Communications Paradigm................................................................................................................. 8117.10.2 SOAP and SOAP with Attachments............................................................................................................8117.10.3 JAX-RPC.................................................................................................................................................... 8217.10.4 JAXM......................................................................................................................................................... 8217.10.5 Web Services Best Practices................................................................................................................. 8217.10.6 The Web services interoperability promise is built on four major layers of industry specifications.. .8217.10.7 General Guidelines.................................................................................................................................. 8317.10.8 CODE to WSDL...................................................................................................................................... 8417.10.9 WSDL to Code........................................................................................................................................ 8517.10.10 Defining operations............................................................................................................................... 8617.10.11 General Naming Conventions.............................................................................................................. 8617.10.12 Software Processing Considerations...................................................................................................8617.10.13 Platform Interoperability Considerations..............................................................................................8717.10.14 WSDL RELATED RECOMMENDATIONS..........................................................................................8717.10.15 WSDL Document Structure.................................................................................................................. 8717.10.16 Imports and Includes............................................................................................................................. 8817.10.17 Specifying Types Section..................................................................................................................... 8817.10.18 Specifying Message Types and encoding styles................................................................................8817.10.19 RPC XML featurSOAP encoded.......................................................................................................... 8917.10.20 Document/Literal................................................................................................................................... 8917.10.21 Parameter Wrappers............................................................................................................................. 9117.10.22 Port Types............................................................................................................................................. 9417.10.23 SOAP Binding....................................................................................................................................... 9517.10.24 Services................................................................................................................................................. 97



17.10.25 Creating extensible interfaces.............................................................................................................. 9717.10.26 Publishing WSDL for your clients......................................................................................................... 9817.10.27 Use of common message headers......................................................................................................9817.10.28 Web Service Security.......................................................................................................................... 10017.10.29 References.......................................................................................................................................... 100



1.0 Overview

The purpose of this document is to provide development standards and guidelines for members of the development team on the VERIZON Supply Chain Transformation (SCT) project. The standards and guidelines cover all the SAP development application areas including ABAP/4 programming language, Workflow, Portals, EAI WebLogic Integration and Business Warehouse (BW).

The objectives of the standards and guidelines contained in this document are to: Produce a common framework for all developers on the VERIZON SCT development team. Produce consistent naming conventions. Produce consistent and reliable results. Allow for easier maintainability (improved productivity / customer service). Provide guidelines where definite standards have not been enforced. Provide a source document that will be periodically reviewed and updated.

The naming standards contained within this document are not intended to be complete, but rather continually enhanced via new suggestions, improvements, standards and technologies.

The Programming standards and guidelines contained in this document are primarily designed for developers who are either employed at, or under contract to the VERIZON SCT Project.

When ABAP programming is required in context of SAP BW, the standards and guidelines set forth for the ABAP Development Standards will be utilized.

In the ABAP/4 development environment the terms "Report" and "Program" are used to describe written developments, created using the ABAP/4 Workbench. For clarification purposes, the terms "Report" and "Program" are considered to be one and the same.

2.0 Programming Standards DefinitionsABAP Advanced Business Application Programming

Shall/Will An imperative. The statement will apply in every case.

No exceptions.

Should A very strong preference. The statement will be

adhered to wherever possible.

Assumed By default the statement will be adhered to.

Recommended The adherence of the statement is preferred.

Standard Reporting Involves selecting, editing, and sorting data; processing

control levels, calculating totals, producing statistics,

etc

Interactive Reporting Select report data using line selection, PFKEYS,

windows, split screens, etc.



Dialog Transactions Covers the area of calling Dynpros, sending messages,

locking and releasing data records, updating, etc.

3.0 Development Methodology

The Development Methodology describes the steps used to fulfill a development request from start to finish. All team members requiring custom development must follow the methodology to have work requests approved, prioritized, and scheduled for completion. It is important for those working on development tasks to realize that excessive change can have an adverse effect on project timelines. A procedure for controlling change and resolving issues during and after development is included in the methodology. Team members should also be aware of any roles and responsibilities that they may be assigned during the course of the development process. For the purposes of the VERIZON SCT project, the overarching development methodology to be followed is VERIZON SCT ’s Software Development Framework (SDF).



4.0 Development Guidelines

ABAP/4 programs should adhere to the following coding guidelines:

Authorization checks are required at the transaction level for all programs, and coded within the program itself if applicable. Programs will be executed by users in an assigned transaction code.

Only custom VERIZON SCT defined tables should be directly updated by a program. SAP tables should be modified by SAP standard methods (eg. BAPI, IDOCS, etc.)

All programs should use structured programming techniques and a top down methodology, where applicable. Use Pretty Printer option of the ABAP editor to help align elements.

Open SQL call should be avoided, Use Select Single when selecting records using the key fields. Select only the fields of a table required by the program. This will increase performance and decrease the amount of data sent between the dB server and the Application server. When possible, read data into an internal table with one select statement, then loop through the table rather than nesting Select – Endselect loops.

Use Explicit work area to hold the data from the select statements Use CLEAR < > for variable initialization or reset. Global variables are restricted as follows

If variable data is used by only one routine, a local variable must be defined. If variable data is used by multiple routines, a global variable or routine invocation with

parameters may be used (programmer’s discretion) Variable names should not contain hyphen ( - ), use underscore ( _ ). Messages should be maintained using message class. The first 100 messages from each message

class will be used for messages common to other programs. All variables should have meaningful names and should indicate what they are used for. There will be no literals used or hard coded values within the code. Input and output structures should use field names as identified in Data Dictionary. All opens and closes of files should be done in the main routine. Sequential files access should have only two reads, one to prime the process and one for

sequential processing to end of file. The main routine and all subroutines should be structured to avoid large or overly complicated

code. Break source down into simpler code sections (internal subroutines, macros, includes or function modules).

Similarly, common code should be maintained in an include or function module. Subroutines should be in either alphabetical order or call sequence order within the program. Upon the program's conclusion, a return code should be set identifying successful completion,

error, or abnormal termination. When using the key word SORT to sort an internal table, use the BY parameter as often as

possible. This will increase performance. Use Binary Search when reading large internal tables (> 20 rows). Sorting the internal table is much faster than using the ORDER BY in the select statement.

Set the OCCURS = 0 for internal tables unless you have a good size estimate (Use “INITIAL SIZE” for new development.)

Using the ASSIGN keyword should only be done when there are no other possibilities. This key word generates a heavy load on the system and adversely affects performance.

When using a logical database, utilize a database with minimal levels (even if one must be created). Is the program using SELECT * statements? Convert them to SELECT column 1 column 2 or use

projection views. Are CHECK statements for table fields embedded in a SELECT … ENDSELECT loop? Incorporate

the CHECK statements into the WHERE clause of the SELECT statement.



Do SELECTs on non-key fields use an appropriate Database Index or is the table buffered? Create index for the table in the data dictionary or buffer tables if they are read only or read mostly.

Is the program using nested SELECTs to retrieve data? Convert nested SELECTs to database views, database joins or SELECT … FOR ALL ENTRIES IN ITAB.

Are there SELECTs without WHERE condition against files that grow constantly (BSEG, MKPF, VBAK)? Program design is wrong - Back to the drawing board.

Are SELECT accesses to master data files buffered (i.e. no duplicate accesses with the same key)? Buffer accesses to master data fields by storing the data in an internal table and filling the table with the READ TABLE.. BINARY SEARCH method.

Is the program using SELECT .. APPEND ITAB .. ENDSELECT techniques to fill internal tables? Change the processing to read the data immediately into an internal table (SELECT VBELN AUART … INTO TABLE IVBAK…).

Is the program using SELECT ORDER BY statements? Data should be read into an internal table first and then sorted, unless there is an appropriate index for the order by fields.

Is the programming doing calculations/summations that can be done on the database via SUM, AVG, MIN or MAX functions for the SELECT statement? Use calculation capabilities of the database via SELECT SUM…

Are internal tables processed using the READ TABLE itab WITH KEY technique? Change table accesses to use BINARY SEARCH method.

Use “COMMIT WORK” in long running program to free up DBM locks. Commit frequency should be an input parameter, and varies with the nature of the application. Beware that COMMIT WORK may loose your cursor positioning.

Is the program inserting/updating or deleting data in dialog mode (not via an update function module)? Make sure that the program issues COMMIT WORK statements when one or more logical units of work (LUWs) have been processed.

In addition, Workflow should adhere to the following policies and guidelines:

Workflows will not have attachments linked to the actual workflows. Any necessary attachments should instead be linked to the SAP document itself (such as FI document) and stored through the VERIZON SCT - approved document management system as described in the business requirements. Part of the reason for this is because after archiving workflow with attachments, any retrieval from archiving might or would lose the links to these attachments.

Workflow development objects should be built once, and if appropriate, reused by other processes.



5.0 Program Structure

An important aspect of any programming standards is the need to define the Standard Layout of the program. This requirement is critical in producing commonly structured programs.

A skeleton ABAP/4 program exists to illustrate the standard program layout. The skeleton ABAP/4 standard program ZCMN_TEMPLATE must be used as a source document to use as a pattern when creating a new program.

Each new ABAP/4 program shall contain both:

External Key Elements

Internal Key Elements

6.0 External ABAP/4 Program Elements

External program elements refer to a program characteristic that is external to the actual program source code.

6.1 Selecting a Program Name

Program identification - in compliance with the document "Naming Standards for SAP" (please see section Naming Conventions for referral to naming standards).

6.2 Text Elements

The use of hard coded text literals will not be permitted in ABAP4 programs. All Text literals shall be declared as "Text Elements" within an ABAP/4 program.

Example:

WRITE: TEXT-001 (Standard)

WRITE: "Material number..."(Non Standard)

6.3 Attributes

Type 1 - Executable program I - Include program M - Module pool F - Function group S - Subroutine pool J - Interface pool K - Class pool

ApplicationApplication types are:

A - Asset Accounting



B - Business Information Warehouse C - PPC (Production Planning) D - DASS (control station) E - RIVA F - Financial accounting G - General ledger H - Personnel Planning I - Plant maintenance J - Publishing K - Cost accounting L - Inventory management M - Material management N - Hospital P - Human Resources Q - QSS (Quality assurance) R - Unknown application S - Basis U - Enterprise Data Model V - Sales W - MMS (Merchandise mgt. System) Y - Customer head office Z - Customer branch * - Cross-Application

TitleThe title of the program shall correspond to the title of the report being created by the ABAP/4 program.

Development Packages

In the VERIZON SCT development environment, related objects in the ABAP Workbench are grouped together in a package. The assignment of an object to a package is entered in the object directory (TADIR). The package determines the transport layer that defines the transport attributes of an object. Packages have been identified for use when assigning Correction numbers to changes you make to Development Objects. When you are presented with the screen that asks for information on the attributes of the Object you are changing, you will see a field titled "Package". This is where you will enter the new Packages. Use the Package that pertains to the area for which you are doing the work. The number “1” in the development packages has been added to separate Phase 1 development objects. Additional Packages will be created when necessary.

Z1MM - SAP Materials Management Z1PP - SAP Production Planning Z1MDM - SAP Master Data Management Z1BC - SAP Basis Components Z1CA - SAP Cross-Application Components Z1FI - SAP Financial Accounting (includes CO) Z1SRM - SAP Supplier Relationship Management Z1SD - SAP Sales & Distribution Z1APO - SAP APO Z1COMN - SAP Common ABAP Development Z1BW - SAP BW Components Z1WF - SAP Workflow specific Components Z1PR - SAP Portals


sapevent:DOCU_LINK/DS:DE.DEVLAYER


7.0 Internal ABAP/4 Program Elements

Internal program elements refer to those program characteristics that directly relate to the ABAP/4 program source code.

The following Internal Program elements will be documented: Documentation box Declarative elements Event elements Control events Operational events

7.1 Documentation Box

The documentation box will be the first element to be declared within an ABAP/4 program. The documentation box is used to describe the characteristics of a program at a summary level. See skeleton program ZCMN_TEMPLATE for an example.

Each item contained within the standard documentation box is detailed below:

PROGRAM NAME - Short Description of program

SAPNAME - Name of the ABAP/4 program

CREATION DATE - Date the program was written.

e.g. 01/01/2005

APPLICATION - Identify the SAP application to which this ABAP/4 program applies.

e.g. MM - Materials Management

SD - Sales & Distribution, etc

AUTHOR - The name of the person who has written the ABAP/4 program.

DESCRIPTION - Description regarding the purpose for this program being written.

TYPE - The type of program written.

e.g. "1" – Executable Program

"M"- Module Pool

"J" - Interface Pool

"I" - Include Program

"S" - Subroutine Group

"F" - Function Module

"K" – Class Pool

INPUTS - Identify all inputs to this program, including Files, etc.

OUTPUTS - Identify all outputs of this program, including Reports, Files, Batch

inputs, etc.

EXTERNAL

ROUTINES

- List all external routines called by this program (ie. Function Modules,

Transactions, Programs)

RETURN CODES - List the meaning of all return codes that this program generates.

AMENDMENTS - The last date that the specifications to this program were revised.



- All subsequent program amendments must be documented to provide

an accurate maintenance history. Each amendment must detail the:

Amendment no. (Maintenance request number or the next

sequential number allocated)

Programmer making the change.

Date of the change.

Description of the change.

- Each amendment should be appended on the end of the last program

amendment.

7.2 Declarative Elements

The term "Declarative Elements" is used to describe those available ABAP/4 elements that are necessary to define the internal environment that an ABAP/4 program will run under. As part of this standard, each new ABAP/4 program shall only include those declarative elements required of the program in accordance with the program specifications.

Throughout all the declarative elements defined for an ABAP/4 program, the exact level of indentation will not be enforced, but the level of consistency will. (i.e. declarative elements can be indented 3 or 5 characters, etc., but the indentation will be kept consistent.)

Also at least one single blank line shall separate each new declarative element.

The following declarative elements are described below:

REPORT TABLES SELECT-OPTIONS PARAMETERS DATA FIELD-GROUPS FIELD-SYMBOLS



REPORT elementThe REPORT element shall start in column one on the next line after the documentation box, with any associated parameters consistently indented to the right of the REPORT element.

The "NO STANDARD PAGE HEADING" parameter must be included for those ABAP/4 programs that produce report(s) as output. The common heading routine in the skeleton ABAP/4 program (ZCMN_TEMPLATE) will control the formatting of all report headings and therefore the standard ABAP/4 page heading must be made inactive.

Example:

REPORT ZFIOOOlA NO STANDARD PAGE HEADING

LINE-SIZE 132

LINE-COUNT 65

MESSAGE-ID ZZ.

When using the MESSAGE option in your ABAP to send messages back to the user you must first define any new messages in the message class being used. No hard coded messages will be allowed.

TABLES element

The TABLES element shall start in column one with all tables declared on the subsequent lines. Each table will

commence on a new line and be consistently indented. The ordering of declared tables will not be enforced as

part of this standard. For documentation purposes, include a line comment to the right of the table name to

indicate the short description of the table as it appears in the data dictionary.

Example:

TABLES: BKPF, "Accounting Document Header

LFlA, "Vendor Master (General Section)

T001, "Company Codes

T001W. "Plants/Branches

SELECT-OPTIONS elementThe SELECT-OPTIONS element shall start in column one with all select-options declared on the subsequent lines. Each select-option will commence on a new line and should be prefixed with an “S_” and be consistently indented. Add selection texts for each select-option to make the selection screen more users friendly.

Example:

SELECT-OPTIONS:

S_USERID FOR SY-UNAME,

S_DOC_DATE FOR SY-DATUM.

PARAMETERS elementThe PARAMETERS element shall start in column one with all parameters declared on the subsequent lines. Each parameter will commence on a new line and should be prefixed with a “P_” and be consistently indented. Add selection texts for each parameter to make the selection screen more user friendly.

Example:

PARAMETERS:

USERID LIKE SY-UNAME,



DOCDAT LIKE SY-DATUM,

DTL TYPE C DEFAULT "Y".

DATA elementThe Data element shall start in column one with all data work fields declared on the subsequent lines. Each data work field will commence on a new line and be consistently indented. The data work field type and value definitions must also be aligned. The only exception is for structure definition utilizing the “INCLUDE STRUCTURE” format (see below).

As part of these programming standards it is highly recommended that wherever possible the reference to data dictionary fields and structures be used by programmers when developing ABAP/4 programs. The ABAP/4 programming language offers many benefits with regards to available commands and statements when data dictionary fields are referenced.

It is for this reason that the LIKE attribute be used to define work fields where possible under the data element area of the program.

Data work field naming conventions will not be enforced as part of these programming standards, although meaningful assignment of names will be required.

Individual Work Fields

Individual work fields should be prefixed with “g_” for global and “l_” for local variables.

Example:

DATA:

G_USERID LIKE SY-UNAME,

G_DOC_DATE LIKE SY-DATUM,

L_DTL_RPT TYPE C DEFAULT 'Y',

L_ACCT_NUM TYPE N VALUE 0.

Internal Table Work Fields (include structure; multi-line exception)

Internal tables should be prefixed with “GI_” for global and “LI_” for local internal tables.

Example:

DATA: BEGIN OF GI_CUSTOMER_STRUCTURE.

INCLUDE STRUCTURE KNA1.

DATA: END OF GI_CUSTOMER_STRUCTURE.

Internal Table Work Fields (Single & Multilevel)

Examples:

DATA:

BEGIN OF DATE,

MONTH (2) TYPE C,

DAY (2) TYPE C,

YEAR (4) TYPE C,

END OF DATE.



DATA:

BEGIN OF USERIDS OCCURS 50,

CODE (5),

NAME LIKE SY-UNAME,

ACCT (1 0),

END OF USERIDS.

Objects

Examples:

DATA:

<instance> TYPE REF TO <classname>.

FIELD-GROUPS elementThe FIELD-GROUPS element shall start in column one with groups defined on the subsequent lines. The first field-group will always be "HEADER" (available sort fields), followed by the remaining groups which must be meaningfully named.

The INSERT statement required to insert field names into each field-group will immediately follow the FIELD-GROUP declaration. Each new INSERT statement shall also start in column one and have the first field name indented. The fields to be inserted shall reference those corresponding data dictionary names where possible. This will make coding benefits available with several of the ABAP/4 command statements.

Examples:

FIELD-GROUPS:

HEADER

DETAIL.

INSERT:

LFA1-LIFNR

LFAl-LANDl

INTO HEADER.

INSERT:

LFAl-STRAS

LFAl-ORT01

INTO DETAIL.

FIELD-SYMBOLS elementThe Field-symbols element shall start in column one with the field-symbols indented on the subsequent line(s).Each field-symbol shall be assigned a meaningful name. Field symbols should be prefixed with “FS_”.

Examples:

FIELD-SYMBOLS:

<FS_ACCT_CD>, <FS_STORE_LOC>.



7.3 Event Elements

Within the ABAP/4 programming language there exists several programming events. A programming event signals the execution of a specific set of program statements (block of code), at a specific point, during program run time.

The following event elements are documented below:

INITIALIZATION

START-OF-SELECTION / END-OF-SELECTION

GET / GET LATE and other DB related statements

TOP-OF-PAGE

INITIALIZATIONThis event shall always be present for those ABAP/4 programs with a selection screen. It is essential that this event always be the prior event to the Start-of-Selection event. Care should be exercised with regards to the programming logic contained in this event, as the Initialization event is not executed in batch.

Data declarations shall not be defined after this event, as during a program batch execution the data fields will not be known to the program.

START-OF-SELECTION / END-OF-SELECTIONThe events Start-of-Selection and End-of-Selection shall always be present in all ABAP/4 reporting programs. The End-of-Selection event will be used to execute among other things the standard subroutine "REPORT_HEADER", so that titles of reports will be printed. The standard routines will need to be developed at a later time within the phase 1 of implementation.

GET / GET LATE and other DB access related statementsThe event GET LFAl will access the table LFAl. As part of these standards the GET event shall only be used with a database table. The GET event shall only be used in conjunction with a table that requires specific processing.

Example:

(Non Standard)

GET LFAl.

GET LFB1.

CHECK LFB1-BUKRS = '0010'.

WRITE: / LFB1-EIKTO.

(Standard)

GET LFB1.

CHECK LFB1-BUKRS = '0010'.

WRITE: / LFB1-EIKTO.



All table fields accessed and subsequently referenced in an ABAP/4 program shall always have the field prefixed with its table name, etc. to uniquely identify the source of the data field. The one exception to this is the use of table fields in connection with the AT...ENDAT construct.

The ABAP/4 programming language allows program data fields which are unique to the program, to be referenced without a prefix.

Examples:

LFB1-BUKRS, (Standard)

BUKRS, (Non Standard)

It is recommended that all access to files be through the use of logical databases. Accesses to individual table should be kept to a minimum.

TOP-OF-PAGEAll ABAP/4 programs that produce list report(s) must contain the TOP-OF-PAGE event. This event is executed at each new page when generating the report, and therefore will be used in these programming standards to control and print the program headings.

A function module has been written to control all header and footer detail lines, of all ABAP/4 report generating programs.

7.4 Control Events

Controlling events within the ABAP/4 programming environment are used to control the flow of the program within processing blocks. There are several controlling elements available, with their description and functionality described below:

IF.... ELSE...ENDIF

DO...ENDDO / WHILE....ENDWHILE

CASE....WHEN....ENDCASE

ON CHANGE OF......ENDON

LOOP....ENDLOOP

LOOP TERMINATION

TERMINATION OF PROCESSING

SUBROUTINES

FUNCTION MODULES

AUTHORITY-CHECK

IF.... ELSE...ENDIF.When coding nested IF statements within a program, no more than three nests shall be structured, at such a point a PERFORM call or CASE statement will be executed. This standard will restrict lengthy control events congesting a program, and making it difficult to read.Each matching IF...ELSE...ENDIF will be consistently aligned and indented.

Example:



IF BKPF-BELNR = INVOICE_NUMBER.

PERFORM PROCESS_INVOICE.

ELSE.

PERFORM CHECK_DOCUMENT_NO.

ENDIF.

When a program variable is repeatedly evaluated for discrete values the IF.... ELSE...ENDIF statement shall be replaced with the CASE.... WHEN.... ENDCASE construct.

Example: 1

(Non Standard)

IF LFB1-EIKTO = '00014000'.

<.....CODE.....>.

ELSE.

IF LFBl-EIKTO = '00014500'.

<...CODE...>.

ELSE.

IF LFBl-EIKTO = '00014800'.

<....CODE....>.

ELSE.

IF LFB1-EIKTO = '00015000'.

<....CODE....>.

ENDIF.

ENDIF.

ENDIF.

ENDIF.

Example: 2

(Standard)

CASE LFB1-EIKTO.

WHEN '00014000'.

<....CODE....>.

WHEN '00014500'.

<....CODE....>.

WHEN '00014800'.

<....CODE....>.

WHEN '00015000'.

<....CODE....>.

WHEN OTHERS.

<....CODE....>



ENDCASE.

The IF.... ELSEIF statement will not be used.

DO...ENDDO. / WHILE...ENDWHILE.

The Do...Enddo. / While...Endwhile control events shall always be coded with a controlled exit point.

Example:

DO 9 TIMES.

SHIFT NAME BY 1 PLACES.

ENDDO.

OR

DO.

READ DATASET 'SAPV01' INTO RECORD.

IF SY-SUBRC NE 0.

EXIT.

ENDIF

ENDDO.

CASE....WHEN....ENDCASE.When coding nested CASE....WHEN....ENDCASE statements within a program, no more than three nests shall be structured, at such a point a PERFORM call will be executed. The WHEN OTHERS clause will be used always. This standard will restrict lengthy control events congesting a program and making it difficult to read.

Each nested CASE....WHEN...ENDCASE statement will be consistently aligned and indented. For program efficiency purposes the most likely 'WHEN' event should be coded first.

Example:

see the control event example for IF....ELSE....ENDIF.

ON CHANGE OF.......ENDON.The ON CHANGE OF control event is preferred to the IF statement when field change evaluation is required. This will eliminate the need to define a work field.

Example:

GET LFAl.

ON CHANGE OF LFAl-LIFNR.

WRITE:/ ’Vendor name:’, LFAl-NAME1.

ENDON.



LOOP....ENDLOOP.To ensure all requested entries in a transparent table are read, the table shall be initialized to spaces.ABAP/4 interprets each value (other than space) in a declared transparent table as part of the generic key, and hence no data will be processed.

Example:

MOVE SPACE TO T005.

LOOP AT T005.

<....CODE... >.

ENDLOOP.

LOOP TERMINATIONIt is recommended, that for readability and maintainability purposes, that loop termination be controlled via the CHECK and EXIT statements.

Example: 1.

GET LFB1

CHECK LFBl-BUKRS = SY-BUKRS.

2.

LOOP AT TAB.

<....CODE....>

IF SY-SUBRC NE 0.

EXIT.

ENDIF.

<....CODE....>

ENDLOOP.

TERMINATION OF PROCESSINGThe REJECT statement shall be used to terminate a currently processed Table and all dependent Tables lower in the logical database hierarchy.

The STOP statement shall be used to terminate an ABAP/4 program's data selection. The END-OF-SELECTION event will be declared in all programs and will be used in conjunction with the STOP statement.

The inclusion of the END-OF-SELECTION event is consistent with the rule of structured programming, of one entry and one exit point.

SUBROUTINESThe use of subroutines is imperative in developing well structured programs. Wherever possible a program should logically organize command statements into subroutines.



The ABAP/4 statements FORM....ENDFORM are used to define the boundaries of a subroutine. Both of these statements shall start in column one, with subroutine statements indented consistently thereafter. Each subroutine shall be prefixed with a standard FORM documentation box and preferably start with the name “SUB_”.

All FORM....ENDFORM constructs shall be placed at the bottom of the program, ordered according to their execution sequence.

An ABAP/4 Program may not call a FORM routine in another program. In this situation the program code that is common to two or more programs shall be incorporated into an INCLUDE member or a FUNCTION MODULE. The programmer, where possible, should refrain from duplicating ABAP/4 code across more than one program.

Example:

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

* FORM Read-purchase-order *

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

* This form reads the purchase order relating to the invoice *

* document stored in the internal table 'INV-DOCS'. *

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

FORM SUB_READ_PURCHASE_ORDER.

IF............

MOVE..............

ENDIF.

ENDFORM.

FUNCTION MODULESThe use of function modules in the ABAP/4 development environment provides the means to execute common processing logic, available to all programs.

Developed Programs shall call function module logic where applicable, rather than re-invent the wheel. Quite often function modules can be enhanced to accommodate variations in the required processing logic.

All declarative elements defined in a function module shall be consistent with those standards and comments documented as part of this document.

Unless indicated otherwise the programming elements permissible in the function module environment, shall conform to the same programming standards which form this document.

AUTHORITY-CHECKAuthority checks are used to prevent the unauthorized execution or restrict the available processing options of an ABAP/4 program. When functional requirements specify that security needs to be applied, an authority check will be included within the program.



If the security provided by using logical databases satisfies the functional requirement then there is no need to include an authority check within the program. A generic authorization object will need to be developed if there are many programs that need it. Additional documentation for how to develop this authorization object is available online in SAP.

Example:

7.5 Operation Events

Operation events are those program events indicated by an operational action.(i.e. MOVE, SUM, APPEND, WRITE,.....etc.)

MOVE-CORRESPONDING / ADD-CORRESPONDING ETC.Fields participating in these special ABAP/4 statements shall, where possible, use the LIKE statement.

Examples:

START-OF-SELECTION.

GET LFA1.

MOVE-CORRESPONDING LFAl TO RECORD.

GET LFB1

MOVE-CORRESPONDING LFB1 TO RECORD.

-------

-------

END-OF-SELECTION.



8.0 Program Comments

The amount of detail with regards to program comments is largely up to the discretion of the individual programmer. The programmer should access the necessary level of program documentation required to fully clarify the purpose and functionality of the program. Program documentation includes both internal and external documentation.

8.1 Internal Programming comments

Program comments shall appear in the documentation box, before complex code and before each FORM routine.

All program comments shall be clear, concise and accurately expressed, with the emphasis placed on the WHAT and WHY aspects.

As part of this standard, all comments shall appear before the coded functionality and will be in the form of a full comment line. Wherever possible it is recommended that full comment lines not be inserted in the middle of control events. (e.g. IF.....ELSE.....ENDIF), to maintain program readability.

Example:

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

* This is an example of a full program comment line. *

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

The ABAP/4 language permits a comment to reside adjacent to a code line. In-line comments will be used for documenting change request numbers, data element definitions and nested end statements. The change request number will appear against those lines modified as part of the program enhancement.

Example:

MOVE: LFAl-LIFNR TO LFB1-LIFNR, "example of in-line comment

LFAl-NAMES TO LFBl-NAME1.

When modifying an ABAP/4 program, lines to be deleted or changed shall be copied and commented out. All lines of code relating to the change should be commented to the right of the line with the change request number (TMS Request Number). The duplication of program lines provides a program history.

Programs that have had sufficient enhancements made, can become difficult to read when blocks of code are repeated and subsequently commented out. Therefore consideration has to be given to when a program has become too difficult to read, and should be cleaned up ready for another change cycle.

In the following example the number '99999' must match with the sequential number given to the corresponding program amendment. The first amendment number will be '00001', and subsequent amendments will be incremented by one.

Example:

* WRITE:/TEXT-001, TEXT-002. "99999



WRITE:/TEXT-001, TEXT-003. "99999

8.2 External Programming comments

External report documentation can be created using the SE38 transaction and selecting the Documentation button.



9.0 ABAP/4 Coding Techniques

This section of the document is for miscellaneous programming techniques. Not all of the documented techniques will be enforced as part of the programming standards, although the use of the recommended programming techniques is encouraged where appropriate.

9.1 Data Selection

When an ABAP/4 program is executed it reads the selected data from the relevant databases based on evaluations according to the report's specifications. Therefore strong consideration should be given to the controlled restriction of unwanted database accesses. The use of precise specifications within all programs will significantly enhance program performance.

The ABAP/4 programming language permits the specification of multiple statements on one physical line of code. To increase program readability, each ABAP/4 statement shall be coded on an individual line.

The practice of chaining identical ABAP/4 statements, can increase program readability and remove redundant statements.

Large processing blocks of code shall be broken down into logical units of work and performed as subroutines. The use of subroutines develops structured programs that are easier to read and maintain. Subroutines shall be ordered in the sequence the system executes, to aid in reading the program.

The programming standards support the ready made key work structures available in the ABAP/4 language. In the SAP ABAP/4 editor SE38 templates can be inserted for each function call by first placing the cursor on the line where the code is to be entered and then by pushing the Insert Statement button). Next select the function.

Frequently used constants shall be defined with a VALUE clause in the DATA declaration area. Frequently used data declaration structures shall be defined as Include programs.

Programs that contain arithmetic computations shall have 'Fixed Point Arithmetic' set in the program attributes. Fixed point arithmetic allows an ABAP/4 program's computations to be performed as would a standard calculator. Program debugging and maintenance will be made easier with this attribute set.

All numeric fields used in calculations should be setup as packed. Numeric fields are stored as packed in the database. Calculations should be performed on packed fields. For incrementing numeric field values use the following syntax: FIELDA = FIELDA + 1.

Use internal tables as work areas for database tables when practical. Reference tables used repeatedly in a program are candidates for loading internally into ABAP. If all the fields are needed, use the STRUCTURE syntax. Otherwise, name each field in the internal table the same as the database field and use the LIKE construct to define the attributes. In that case use the SELECT ...INTO. The structure of the internal table must be identical to the database so use the STRUCTURE syntax. Another option is to create a projection view in the data dictionary. Then structure the internal table off the projection view. It is then possible to select * from the projection view into the internal table. Be as restrictive as possible with the WHERE clause to reduce the answer set. Data should be read into an internal table first and then sorted, unless there is an appropriate index for the order by fields.



Internal tables are a dynamic data structure. Their memory requirements are met in blocks. The initial memory allocation (hereafter called the OCCURS area), can be controlled using the "OCCURS n" or "INITIAL SIZE n" addition in the table definition (DATA, TYPES). Once the OCCURS area is full, the next block to be created is twice as big as the OCCURS area (as long as this is not greater than 8 KB). All further blocks are then created with a constant size of 12 KB.

You can leave it to the system to determine the size of the OCCURS area by specifying n = 0. In this case the system allocates only a "small" portion of memory at the first INSERT or APPEND statement. "OCCURS 0" or "INITIAL SIZE 0" means that 16 <= n <= 100 (depending on the line width). It only makes sense to specify a concrete value of n > 0 when you know exactly how many entries the table will have, and you want to set up the OCCURS area exactly. This can be particularly important if you want to nest internal tables (where an "outer" internal table contains one or more other internal tables in each line, and the "inner" tables only have a few entries (no more than five, for example).

To avoid excessive memory requirements, the system handles large values of n as follows: The largest possible value of n is n_max = 8 KB divided by the line width. For larger values, n is set such that n multiplied by the line width is around 12 KB.

9.2 Program Identifiers, Constants and Variables

All program identifiers, constants and variables shall be assigned meaningful names that are clearly understood.

Constants shall be declared with the VALUE clause in the data declaration part of the program. Table ZTXEDIT can be used to store constants and reference values for program execution. The interface / conversion / enhancement ID should be used for storing these values in this table.

Variables with the same name shall not be declared as both global and local. This standard will eliminate confusion when reading through the program.

9.3 Flags

Programming flags should be replaced with alternative logic wherever possible. A flag shall only be assigned a 'Yes' or 'No' value, represented by 'Y' and 'N' respectively.

9.4 PFKEYS Usage

The standard SAP PFKEYS assignment shall be used when programming interactive reports. The SAP system has default settings for these particular PFKEYS.

The SAP standard PFKEYS are listed below:

PFl Help PF2 Choose PF3 Back

PF4 Possible EntriesPF8 Execute PF9 Editor, Long Text, Select/Deselect

PF10 Menu bar PF11 Save PF12 Cancel

PF14 Delete PF15 Exit PF16 Hold, Save without Check, Sort

CTRL+F Search

CTRL+G Search Again



CTRL+P Print

CTRL+S Save (PF11)

CTRL+PAGE UP First Page

CTRL+PAGE DOWN Last Page

PAGEUP Previous Page

PAGEDOWN Next Page

PFKEYS assigned to an ABAP report shall be done so with a PFKEYS status. The command statement SET PF-STATUS 'wxyz' shall be used in the program to reference the correct PFKEY assignments.

Text used in conjunction with the PFKEY definition, should conform where possible to the SAP standards. (i.e. PF: n=description)

The most commonly used PFKEY selection shall be displayed as part of the screen Text.

To indicate the availability of more PFKEYS, the standard SAP text of '.....' will be used at the end of the PFKEYS text line.

All PFKEYS will be documented in the PFKEY window, when defining the PF-status. This text will be made available when the PFl key is pressed.

Example:

PF3 = Back

PF8 = Execute

9.5 Screen Painter Standards

The Screen Painter standards apply to those customized developments involving the creation of tables and transactions.

Dynpro names will always be defined to the data dictionary.

Dynpro sequencing shall be controlled dynamically from within the module pool.

The SET SCREEN statement shall be coded for each possible logical path that can be taken in a Dynpros PAI processing logic. This will make the transaction easier to read.

When developing Dynpros the PFKEYS and space bar should be used to make alterations to Dynpro lines. A Dynpro can become corrupted if the normal keyboard delete and insert keys are used.

The commands 'INPUT and 'OUTPUT' will be defined with all respective PAI and PBO modules. This will eliminate modules being incorrectly processed, as the SAP system assumes each module is a PAI unless specified otherwise.

Example:

MODULE SET_SCRN_ATTR OUTPUT.

MODULE PROCESS_PFKEYS_9000 INPUT.



The CHAIN command shall be used to group logical fields together before calling a module. This will aid the end user in error corrections.

The processing logic command ON CHAIN INPUT and ON CHAIN REQUEST shall be used to reduce redundant processing.

Example:

CHAIN.

FIELD LFA1-LIFNR.

MODULE CHECK_VENDOR_9000 ON CHAIN REQUEST. ENDCHAIN.

When dialog messages are issued on a Screen Painter Dynpro that relate to an individual field, the cursor shall be dynamically positioned on the field.

Example:

SET CURSOR FIELD 'LFAl-LIFNR'. (Standard)

SET CURSOR 6 10. (Non Standard)

The EXIT FROM STEP LOOP statement shall be used where premature termination of Dynpro loop processing is required.

The naming standards regarding Dynpros and module pool shall be found in the Naming Standards section of this document.

Transactions that change the SAP databases shall check whether the desired record is free to be changed. This check will ensure data integrity is maintained. The ENQUEUE / DEQUEUE statements shall be used to individually lock data records.

For the purposes of this standard, a database update shall be any modification, deletion or insertion of a database record or external table.

An update program, of type 'V', shall be written for any database or ATAB table updates. Within this update program, there will be a FORM subroutine that, when executed, will perform the desired database update.

It is recommended to not update any SAP database table with a written program. Use the SAP transactions to process transactions.



10.0 Reviews

10.1 Requirement and Design Reviews

Reviews are mandatory for application development. The following are the guidelines to be used for the internal project team reviews. Formal quality peer reviews and inspection point guidelines for compliance with SDF will be documented and distributed by the Methodology Assurance team.

Design document Author plans and schedules the appropriate review meeting(s). Required attendees should include:

Developer that will work on the application Technical Team Leader to moderate the meeting, cancel meeting if insufficient attendance

or reviewers not prepared, resolve any disputes that occur. Technical Consultant who will assist in any questions/concerns pertaining to the

specification Optional attendees should include:

Functional Owner that worked on the requirements Application Team Leader (Functional),resolve any disputes that occur. Application Consultant (Functional) will also assist in any questions/concerns pertaining to

the specification. Design document Author distributes Documentation prior to the review. Reviewers examine the documentation prior to the meeting noting any deviations to the guidelines

and any other problems. The design document Author designates a recorder to document the meeting into meeting minutes. The meeting’s output is a list of issues with assigned owners and due dates At a minimum, the following items should be checked during the review:

Does the design document specification conform to the guidelines set forth? Are all mandatory sections filled in with enough information? All record layouts, inputs and outputs must be documented. Referring to existing

documentation is fine. Abnormal conditions must be addressed.

The review team must decide if a follow up review is required. Review will be limited to 30 minutes to one hour in length.

10.2 Code Reviews

Code reviews are required for all application development. Code reviews should be held to inspect code for correctness and efficiency. It is an ideal way to help educate programmers to a new application or coding language. It also helps keep code consistent with the standards provided for program development. The following is a list of the participants in a code review and their responsibilities:

Author of program Schedules the code review. Chooses reviewer from distributed list Distributes code prior to review. Documents the meeting. (minutes) Corrects code as needed.

Reviewer Experienced ABAP developer, senior level Reviews code based on a provided checklist prior to meeting. Provides input to the author of any deviations from guidelines



Provides suggestions to the author for improvement on performance Team Leader

Reviews results Resolves disputes



11.0 SAP Naming Conventions

SAP provides reserved name spaces (i.e. ranges of available object names, usually beginning with the letters Y or Z). Customer object names use these reserved name spaces to avoid unintentional overlaps when importing a new maintenance level or release upgrade of SAP.

In the SAP standard naming convention, Z is for the use of the branch office and Y is for head office. Within this project we will use Z for object names that are developed for use in production. We will use Y object names for local private objects created during testing and experimentation by individual developers. Objects using the Y naming convention will never be transported.

The naming convention put forth in this document is established to comply with SAP's defined customer reserved limits, and also outline rules concerning those freely definable characters within the object name.

The following conventions are used throughout this document for our naming conventions:

Upper case (capital) letters are to be entered as shown. Lower case letters are to be interpreted as follows:

x any alphanumeric character

n any numeric character

t Type of program

C ConversionI InterfaceR ReportE EnhancementU UtilityN IncludesF Forms W WorkflowP Portals

MNnnn Functional Specification ID without the prefix FS i.e. module name + object number

Example: For functional specification FSFI001, use the ID as FI001

11.1 Program Naming

11.1.1 Local Private Programs

Format:Yflx…x

Length: up to 30 characters

Where: Y Constant for local private programf First initial of owner's first name



l First initial of owner's last namex…x any alphanumeric characters

Note: If another developer has the same initials, add a letter or number to make it unique.

11.1.2 Production Programs

Format:Z_o_desc

Length: up to 15 characters Where: Z Constant for customer developed objects

o Interface / Conversion / Enhancement IDdesc Meaningful description

Example:

Z_FII001_FIN_ACC_POSTING

The skeleton ABAP/4 standard program ZCMN_TEMPLATE as shown below must be used as a source document to use as a pattern when creating a new program.

11.2 Data Element

Format:Zxxxx

Preferably use SAP standard data elements which have the similar length and description as you need. If you do not find such a data element then try to limit the name to 10 characters.


Where: Z Constant for customer developed objectsx…x Any alphanumeric characters

11.3 Domain

Format:Zx…x

Preferably use SAP standard domain which have the similar length and description as you need. If you do not find such a domain then try to limit the name to 10 characters.Length: up to 15 characters

Where: Z Constant for customer developed objects x…x Any alphanumeric characters

11.4 Enhancement



Format:Zox…x


Where: Z Constant for customer developed objectso Object typex…x Any alphanumeric characters

11.5 Enhancement project

Format:Zox…x


Where: Z Constant for customer developed objectso Object typex…x Any alphanumeric characters

11.6 Function Routines

Frequently used routines can be created as function modules. These are accessed by ABAP/4 programs through the “CALL FUNCTION” statement and may be shared across programs. Function Modules are grouped within a Function Group. All Function Modules belonging to one SAP business object type should be created in one Function Group, if possible.

11.6.1 Function Groups

Format:Z_o_desc


o Interface / Conversion / Enhancement IDdesc Meaningful description

11.6.2 Function Modules

Format:Z_o_desc


o Interface / Conversion / Enhancement IDdesc Meaningful description. Spell out the name when possible. For Workflow, the first 5 characters

should be one of the following to describe the function module:_CHK_ for Check Function _RCV_ for Receiver Function_TRG_ for Business Transaction Event



_ROL_ for Role Development_WFD_ for Workflow Development

11.7 IDocs

IDocs are configured with a message type, IDoc type, and function module in which to process them. The variable component should be named in a consistent manner. Example: Type ZEXAMPLE01, Message Type ZEXAMPLE, Function Module ZUK_IDOC_INPUT_ZEXAMPLE. 11.7.1 IDoc Type

Format: Z_x…xnn


Where: Z Constant for customer developed objects x…x Any alphanumeric characters nn Numeric designation, ie: ‘01’

11.7.2 IDoc Message Format: Z_x…x


Where: Z Constant for customer developed objects x…x Any alphanumeric characters

11.7.3 IDoc Function Module Format: Z_IDOC_INPUT_Zx…x


Where: Z_ Constants for customer developed objects b Business unit

a Application area Zx…x IDoc Message.

11.8 Lock Object

Format:EZx…x


Where: EZ Constants for customer developed objectsx…x Any alphanumeric characters

11.9 Logical Database



Format:Zx…x


x…x Any alphanumeric characters

11.10 Menu

Format:Zx…x



11.11 Message

11.11.1 Message ID


The following Standard Message classes will be created in the development environment. The first 100 messages within each development class will be used as standard messages common to all programs and the rest will be program specific messages.

ZMM - SAP Materials ManagementZPP - SAP Production Planning ZMDM - SAP Master Data ManagementZBC - SAP Basis ComponentsZCA - SAP Cross-Application ComponentsZFI - SAP Financial Accounting (includes CO)ZSRM - SAP Supplier Relationship ManagementZSD - SAP Sales & DistributionZAPO - SAP APOZCOMN- SAP Common ABAP DevelopmentZBW - SAP BW ComponentsZWF - SAP Workflow specific ComponentsZPR - SAP Portals

11.11.2 Message number

Format:nnn

Length: 3

Where: nnn Any numeric characters 001 – 100 Standard messages for project101 – 999 Program specific messages



11.12 Module Pools

Format:SAPDZox…x Module pool for dialogSAPMZox…x Module pool for screensSAPFZo…x Module pool for subroutinesSAPSZo…x Module pool for update programs


Where: SAPMZ Constant for customer developed module poolso Object ID example ESD001x…x Alphanumeric name for Module pool

Note: It is highly recommended that the Zox…x defined portion of the program name coincide with the name of the transaction that is used for module execution. Transactions have a limit of 20 characters.

Programming Module Pools: A module pool consists entirely of INCLUDE programs. Please use the following examples as your standard:

Data module

INCLUDE MZox…xTOP Header with data declarations including tables

(alphabetically sorted) and DATA statements.

PBO modules

INCLUDE MZbox…xO10 Process Before Output modules

INCLUDE MZbox…xO20

PAI modules INCLUDE MZox…xIl0 Process After Input modules

INCLUDE MZox…xI20

Subroutine modules

INCLUDE MZox…xF10 Subroutines

Where Zox…x corresponds to the characters of the module pool name.

11.13 SAPscript

Form

Format:Zo_x…x


Where: Z Constant for customer defined formso Object IDx…x Any alphanumeric characters

Note: If a SAP delivered form is copied to a Z version and changed it is recommended that as much of the original name be used to the right of the underscore.



11.14 Standard Text ID

Format:ZMnxx


Where: Z Constant for customer developed objectsMn Module namexx Any alphanumeric characters

11.15 Standard Text Name ---- use rstxtran program to transport the standard text.

Format:ZMn_x…x


Where: Z Constant for customer developed objectsb Business unito Object Idx…x Any alphanumeric characters

Style

Format: Zbx…x


Where: Z Constant for customer developed objectsb Business unitx…x Any alphanumeric characters

11.16 SmartForms

Smartforms shall follow the same naming convention as function modules.

11.17 Screens

The name of a screen (or Dynpro) is made up of the name of the module pool and a screen number. The naming convention for module pools is described above. When creating a new screen for custom developed modules the screen number given can be in the range of 0000 to 9999. When creating a new screen for a SAP delivered module pool the screen number is in the range of 9000 to 9999. This is typically done in the case of a screen exit where a screen exit refers to an area of a main screen reserved by SAP developers for customers to design their own screens as customer exits.

Format:nnnn (Custom developed module)9nnn (SAP developed module)

Length: 4 digits

Where: n freely definable digits



9 customer name range in SAP delivered modules

When developing a series of new screens for a transaction, it is recommended that the sequence and interval of screen numbers be structured appropriately. The sequence of screen numbers should reflect the normal flow of screens through transaction processing. Major screens should be numbered in intervals of 100 (one hundred) and minor screens (including pop-up windows) should be numbered in intervals of 10 (ten).

For example: 0100 Initial selection screen0110 Subscreen A on 01000120 Pop-up Window B for 01000200 Second output screen0210 Pop-up Window C for 0200

Final Screen

11.18 Search Helps

Search helps allow the user to display the list of all possible input values for a screen field. They help the user to easily locate an entry by providing minimal selection criteria. The help displayed can include key value entries along with text descriptions.

Format:Zx…x


Where: Z Constant for customer developed objectx…x Any alphanumeric characters

11.19 SPA/GPA Parameter

SPA/GPA Parameter Ids are used to define default values for entry fields. The defaults are defined in the user master record and linked to a field through the field’s data element definition.

Format:Zx…x


Where: Z Constant for customer developed objectsx..x Uniquely identifies the parameter ID.

11.20 Tables

NOTE: Table names in SAP are unique by the first 7 characters only.

11.20.1 Transparent Tables

Format:Zx…x





11.20.2 Pooled tables and Cluster tables

Format:Zx…x



11.21 Transaction Codes

Format:Zo


Where: Z Constant for customer developed objectso Object Id

11.22 Views

A view allows an alternative way to retrieve data from a table or groups of tables. You can reduce the number of reads by defining a view that contains related data from several tables. A view is a logical table and is not physically stored. SAP views differ from standard views because only tables already linked by appropriate foreign keys in the DD can be joined.

11.22.1 Database view, Projection view, Maintenance view

Format:ZVx…x


Where: Z Constant for customer developed objectsV Always "V" for viewx…x Any alphanumeric characters

11.22.2 Help view

Help Views are needed when F4 Possible Entries requires more than just the key values stored in a table. Usually the key values (e.g. codes) and the associated texts are required. The view will contain both the key and text fields. Only one help view can be built per table.

Format:H_Zx…x




Where: H_Z Constants for customer developed objectsx…x Any alphanumeric characters

11.23 Variants

Variants (selection criteria) contain program parameters and select-options. Several variants can be stored for a program to control its execution. On-line programs should always use selection criteria to limit its execution time. Since variants are program specific there is a free form naming standard.

Format:x…x


Where: x…x Any alphanumeric characters

11.24 BDC Sessions

Batch Data Communication (BDC) sessions are used to execute batch input of SAP transactions.

Format:bo_x…x


Where: b Business unito Object Idx…x Any alphanumeric characters

11.25 File Names

Data files used for conversions or interfaces will be stored on the application server rather than on user workstations unless functional requirements dictate otherwise. The directory path and location of a file is chosen by using a logical file path and file name combination. It is recommended for ease of use that file names be kept short and meaningful. Refer to section 2.2 Interface Implementation Guidelines in Deliverable 2.6: Interface Design Document for further details. File names will use the following convention.

Format:o_yyyymmddhhmmss.typ


Where: o Object Idyyyymmddhhmmss Any alphanumeric characters.typ file extension type. E.g. .txt, .csv, .dat

All names should be in lower case.

11.26 Classes



Classes are the main object oriented applications in ABAP Objects. They should have the following naming convention.

Format:ZCL_bax…x


Where: ZCL_ Constants for customer developed classesx…x Uniquely identifies the function module. Spell out the name when possible.

11.27 ABAP Objects

The following section provides the recommended naming convention for ABAP objects and Variables.

ABAP classes should be named as ZCL_<class_name>. Unless specified all classes are global, local

classes should be named as ZLCL_<class_name>.

Reference variable should be declared with ‘TYPE REF TO’ ZCL_<class_name>.

In ABAP Objects, instances are created with the command ‘CREATE OBJECT’. Instance should be named

as ZICL_<class_name>.

Components of a class

Methods - Public

Static methods should be named as PU_SM_<method_name>.

Instance method should be named as PU_IM_<method_name>.

Methods - Private

Static methods should be named as PV_SM_<method_name>.

Instance method should be named as PV_IM_<method_name>.

Methods - Protected

Static methods should be named as PR_SM_<method_name>.

Instance method should be named as PR_IM_<method_name>.

Parameters of the method should be named as:Importing parameters I_<parameter name>Exporting parameters E_<parameter name>Changing parameters C_<parameter name>Result (returning) R_<result>

Exceptions for the method should be named as EXC_<exception_name>

Constant attributes should start with MC

Attributes (member variable)

Static attribute should start with SMV

Instance attributes should start with IMV

Attributes (member table)

Static attribute should start with SMT



Instance attributes should start with IMT

It is recommended to have a ‘CONSTRUCTOR’, ‘DESTRUCTOR’, ‘INIT’ and ‘CLOSE’ methods in the

class.

Abstract methods should be named as ABM_<method_name>.

Final methods should be named as FNM_<method_name>.

Events should be named as EV_<event_name>

Event handler method should be named as ON_<event_name>

Interfaces should be named as ZIF_<interface_name>.

11.28 Business Objects

Business objects are identified in the Business Object Repository (BOR) by Object Type (an internal key, technical name, for example BUS2032) and by a corresponding Object Name (a descriptive, English-like name, for example SalesOrder). Both identifiers must be unique across all Object Types.

Business objects are often addressed in applications using the descriptive Object Name, while internally in the BOR they are mostly identified using the Object Type. Initially, only the internal key was used, but the extensive use of business objects has given rise to the need for addressing them using Object Names. For compatibility reasons, both identifiers are now used.

Object Type

Format:ZBUSnnnn


Where: Z Constants for customer developed classesBUS Constant for business objects

nnnn Uniquely identifies the business object type.

The 9000 – 9999 number range is reserved for Workflow-related objects.

Object Name

Format:Zx…x


Where: Z Constants for customer developed classesx…x Uniquely identifies the object name. Spell out the name when possible.

11.29 Workflow Templates

Prefix the standard SAP workflow template Abbr. with a Z when using it to create a custom workflow template abbreviation. If a new custom workflow template is created, the Abbr. should be named according to the following standard.

Format:Zx…x




Where: Z Constants for customer developed classesx…x Uniquely identifies the workflow template abbreviation.

Prefix the standard SAP workflow template Name with a Z. If a new template is created, the template should be named according to the following standard:

Format:Zx…x


Where: Z Constants for customer developed classesx…x Uniquely identifies the workflow template.

11.30 Workflow Tasks

Prefix the standard SAP workflow task Abbr. with a Z when using it to create a custom workflow template abbreviation. If a new custom workflow template is created, the workflow task should be named according to the following standard.

Format:Zx…x


Where: Z Constants for customer developed classesx…x Uniquely identifies the workflow tasks abbreviation.

Prefix the standard SAP workflow task Name with a Z. If a new task is created, the task should be named according to the following standard:

Format:Zx…x


Where: Z Constants for customer developed classesx…x Uniquely identifies the workflow template.

12.0 Business Warehouse (BW)

This section provides naming standards and guidelines for BW objects. The document provides a brief description of the various objects in SAP BW and the naming conventions that will be used for the VERIZON SCT project.

When ABAP programming is required in context of SAP BW, the standards and guidelines set forth in the VERIZON SCT ABAP Development Standards sections will be utilized. The BW objects covered in this document are:

InfoCube Calculated Key Figure ODS Object Variable



InfoSource InfoPackage InfoObject InfoPackage Groups Query Periodic InfoPackage Jobs InfoSet Query Variants Roles Events, Event Chains Restricted Key

Figure

12.1 Infocube

Definition:

An InfoCube is the central data container that forms the basis for reports and analyses in BW. InfoCubes contain two types of data: key figures and characteristics. An InfoCube is a set of relational tables that are arranged in a star schema with a large fact table for recording transaction data at the center and several dimension tables around the fact table. The fact table contains the key figures of the InfoCube while the dimension tables contain the characteristics of the cube. InfoSources (see below) supply data to InfoCubes.

InfoCube Naming:

The Infocube naming convention will closely follow SAP standard naming convention in BW. The format of the name will be as follows:

Format:Zo_enn


Where: Z Constants for customer developed classeso Object IDe Type of the Infocubenn Two digit numeric in range 50 to 99

Types of Infocubes in SAP BW

Type DescriptionC Regular CubeR Remote CubeM Multi CubeT Transaction Cube

Note: If a cube is copied from a standard cube and modified, the name should be the same apart from the first character of ‘0’ being replaced with a ‘Z’. If the cube is created from scratch, then the two digit number should be sequentially assigned starting with 50.

12.2 ODS Object

Definition:An ODS Object serves to store consolidated and detailed transaction data on a document level.

It describes a consolidated data set from one or more InfoSources. This data set can be analyzed with a BEx (Business Explorer) Query or InfoSet Query.



An ODS Object contains a key (for example, document number/item) as well as data fields that can also contain character fields (for example, order status, customer) as key figures. The data of an ODS Object can be updated with a delta update into Infocubes and/or other ODS Objects in the same system or across systems.In contrast to multi-dimensional data storage with Infocubes, the data in ODS Objects is stored in transparent, flat database tables.

ODS Object Naming:

The ODS object naming convention will closely follow SAP standard naming convention in BW. The format of the name will be as follows:

Format:Zo_enn

Where: Z Constants for customer developed classeso Object IDa Application areae Type of the Infocubenn Two digit numeric in range 50 to 99

Note: If an ODS Object is copied from a standard ODS object and modified, the name should be the same apart from the first character of ‘0’ being replaced with a ‘Z’. If the ODS Object is created from scratch, then the two digit number should be sequentially assigned starting with 50.

12.3 InfoSource

Definition:

An InfoSource is a set of logically associated information, which can contain transaction data (stored in InfoCubes) and master data (attributes, texts, and hierarchies stored in separate tables). InfoSources describe all the information available for a business transaction or type of business transaction (for example, cost center accounting).

InfoSource Naming:

Custom InfoSource should always start with a Z. When a standard SAP InfoSource is copied the 0 should be dropped from the name and be replaced by Z. A fully customized InfoSource should also begin with a Z followed by a logical name to describe the InfoSource. The abbreviations used by SAP for various terms in the standard InfoSource should be used where possible

Examples:

1. A copy of the 0FI_FM_1 InfoSource would be given the technical name ZFI_FM_1.2. A custom InfoSource has to be created to report on the sales quotas. The technical name would

therefore be ZFM_BUDGET.

12.4 InfoObject

Definition:



An InfoObject is a generic term for characteristics and key figures in the Business Information Warehouse. InfoObjects are used in InfoCubes and in the three structures that are relevant for data requests extract, transfer, and communication structures.

InfoObject Naming:

Custom InfoObjects should always start with a Z. When a standard SAP InfoObject is copied the 0 should be dropped from the name and be replaced by Z. A fully customized InfoObject should also begin with a Z followed by a logical name to describe the InfoObject. The abbreviations used by SAP for various terms in the standard InfoObjects should be used where possible.

Examples:

1. A copy of the 0MATERIAL InfoObject would be given the technical name ZMATERIAL.2. A custom InfoObject has to be created to report on the sales quotas. The technical name would

therefore be ZSLS_QUOTA.

12.5 Query

Definition:

A query is a data evaluation based on the selection of characteristics and key figures. Queries can be configured according to the way you want to view and navigate through data. Users define queries to analyze the data from an InfoCube.

Query Naming:

As queries are created specific to an InfoCube it is advisable to identify the respective cube in the technical name for easy identification. The standard SAP naming convention is as follows:

Zcube_Qnnnn cube = InfoCube Name or the ODS Object Name as applicable nnnn = four-digit sequential number

Customized queries should use sequential numbers in the range 5000 to 9999. If the InfoCube and query are copies of standard SAP content the sequential number should be maintained for the query.

Queries developed by the BW Team will have a technical name starting with “Y…”.Queries developed by the Business Process Teams will have a technical name starting with “YY…”. BW reconciliation queries will have the query technical name starting with ‘YR’.

12.6 InfoSet Query

Definition:InfoSets are sets of data coming from one table or multiple joined tables. InfoSet Queries report on data that is provided by InfoSets. They are especially designed to report on relational data. InfoSet Queries also support Web reporting, RRI (Report Interface). Presentation of the results is in SAPGUI via SAP List Viewer and on the Web.



The InfoSet Query is not designed for reporting on Infocubes (fact tables). When working with InfoSet queries the following features are not supported: Navigation, hierarchies, delivery of Business Content, currency conversion, variables, exception reporting and interactive graphics in the Web.

Authorization checking of characteristic values is similar to the BEx Query. However, complex selection conditions (e.g. excluding some values) would result in time-consuming checks. Hence, simple selection conditions (values and intervals) are supported only.

InfoSet Query Naming:

The InfoSet Query naming convention will closely follow SAP standard naming convention in BW. The format of the name will be as follows:

ODS_IQnnnn

Where ODS stands for ODS Object namennnn stands for a four digit number (5000 – 9999)

Note:

Customized InfoSets should use sequential numbers in the range 5000 to 9999. If the ODS object and InfoSet are copies of standard SAP content the sequential number should be maintained for the InfoSet.

12.7 Roles

Definition:

A role in BW identifies a person responsible for a specific business area. Roles often correspond to job titles. Roles are associated with tasks and include all activities that are carried out by the respective users.

Role Naming:

The format for custom roles will follow closely the SAP naming convention as follows:ZROLE_nnnn nnnn = sequential number

Copies of SAP standard roles will retain the same sequential number but Z will replace the initial 0. Custom roles will also start with Z and have sequential numbers in the range 5000 to 9999.

Examples:

1. A copy of the customer service manager role 0ROLE_0010 would have the technical name ZROLE_0010.

2. A custom role for technical consultant would have the technical name ZROLE_5000.

12.8 Restricted Key Figures

Definition:



A restricted key figure is a key figure that is restricted to certain characteristic values. It is defined in the query definition and limits the selected data to the values or range of values selected.

Restricted Key Figure Naming:

Restricted key figures are specific to an InfoCube and therefore will include the InfoCube technical name. The format will be as follows:

Zcube_RKnnn cube = InfoCube technical name nnn = sequential number

Custom key figures will have a sequential number starting at 500

Examples:

1. Custom restricted key figure for InfoCube ZFIFM_C01 would have the technical name 0FIFM_C01_RK500.

2. Restricted key figures for custom InfoCube ZIC_C50 would have the technical name ZIC_C50_RK500.

12.9 Calculated Key Figures

Definition:

A calculated key figure is a key figure that is calculated of one or more other key figures. Standard, custom, restricted key figures and other calculated key figures can be used for the calculation.

Calculated Key Figure Naming:

Calculated key figures are specific to an InfoCube and therefore will include the InfoCube technical name. The format will be as follows:

Zcube_CKnnn cube = InfoCube technical name nnn = sequential number

Custom key figures will have a sequential number starting at 500.

Examples:

1. Custom calculated key figure for InfoCube ZFIFM_C01 would have the technical name 0FIFM_C01_CK500.

2. Calculated key figures for custom InfoCube ZIC_C50 would have the technical name ZIC_C50_CK500.

12.10 Variables

Definition:

Variables are parameters of a query that are set in the query definition and are not filled with values (processed) until the query is executed and inserted into a workbook. They function as a store for characteristic values, hierarchies, hierarchy nodes, texts and formula elements and can be processed in different ways. Variables serve for the flexible setting of queries.



Variable Naming:

Following SAP’s naming standard the format for a variable will be:

Format:Zp_nnnnn

Where: Z Constants for customer developed classesp Type of Variablennnnn Meaningful name based on the InfoObject for which the variable is used (max of 5 characters)

Types of Variables:

Type DescriptionS Selection variableI Interval variable, i.e. the user enters a range

of entriesP Parameter variable (single value)T Text variableF Formula variableH Hierarchy variableN Hierarchy node variable

T, F, H and N variables describe the variable type. Whereas S, I and P variables are both of the type characteristic and the acronym stands for the type of parameter selection. The abbreviations used by SAP for various terms in the standard variables should be used where possible.

Note:

Variables are InfoCube independent and should therefore not contain the names of any InfoCubes.

Examples:

1. A custom variable that is used in a query to select on a range of customers would have the technical name ZI_CUSTR.

2. A custom variable that is used to automatically replace the text of a time characteristic based on the entry made would have the technical name ZT_FYEAR.

12.11 InfoPackage

Definition:

Data is requested for a combination of application components, an InfoSource, a Data Source and a source system. For the data request, you create a so-called InfoPackage in the InfoSource tree of the Administrator Workbench. Every InfoPackage and every InfoPackage group is assigned to a variant (see below).

InfoPackage Naming:

The InfoPackage name is entered in the description column.



For Transaction data loads, enter the InfoSource name in the description column and next to it mention whether the data load full upload, initialization of delta and delta load. For Master data loads, enter additional information such as attributes, text or hierarchy.

12.12 InfoPackage Groups

Definition:

InfoPackage Groups facilitate management of logically related InfoPackages. The execution of the InfoPackages within the group can be scheduled through the scheduler or triggered by events in the system. (See next section.)

InfoPackage Group Naming:

The technical names of InfoPackage Groups are system-generated. To help keep track of things, we use the InfoPackage Group description field.

InfoPackage Group descriptions are indicative of the logical unit of work that the grouping performs. Many of BW’s InfoPackage Groups are groups of other InfoPackage groups, organized by functional area (e.g., FI-CO), data type (master or transaction data) and time (daily, weekly, monthly). The general format of top-level InfoPackage Groups is:

ff – ff [Master | Transaction] [Daily | Weekly | Monthly | <Other>]

Examples:

1. InfoPackage name for the InfoSource 0FI_AP_3 (transaction data) should be:

If it is full upload - 0FI_AP_3 Full Update If it is delta initialization - 0FI_AP_3 Delta Initialization If it is delta upload - 0FI_AP_3 Delta Update

2. InfoPackage name for the InfoSource 0Material (master data) Attributes should be:

If it is full upload - 0MATERIAL Attributes Full Update If it is delta initialization - 0MATERIAL Attributes Delta Initialization If it is delta upload - 0MATERIAL Attributes Delta Update

3. InfoPackage name for the InfoSource 0Material (master data) Text should be: If it is full upload - 0MATERIAL Text Full Update If it is delta initialization - 0MATERIAL Text Delta Initialization If it is delta upload - 0MATERIAL Text Delta Update

4. InfoPackage name for the InfoSource 0Material (master data) Hierarchy should be:

0MATERIAL Hierarchy Full Update

Please note that all the Hierarchy updates are full Updates.



12.13 Periodic InfoPackage Jobs

Definition:

When you schedule an InfoPackage group, you may supply a job name. This is not a requirement of BW. If you do not supply a name, the system will generate a string of 25 randomly-generated characters that will be appended to the end of the literal “BI_BTCH,” for example:

BI_BTCH3N73E11VR3YT6SGOA342XME5D.

Such names make it exceedingly difficult to monitor periodically-scheduled data loads. The problem is compounded by the fact that, at the pleasure of BW, these job names can change over time. For the sake of clarity and consistency, the VERIZON SCT BW team will supply job names in accordance with the convention stated below. Note: This convention applies only to periodic, scheduled data loads. There is little to be gained by using this convention with ad hoc, “one shot” data loads.

Job Naming:

InfoPackage job names start with BI_BTCH—we have no control over this. The remaining 25 characters are user-supplied. The format is given below:

Format: BI_BTCH_ZBWa_[InfoPackage Name] | [Periodicity] | [MD or TX]_999

Where “a” is the application area (e.g., FI, PR, HR, etc.); The InfoPackage name should include as much of the InfoPackage name as possible. (Note the underscore between the functional area and the start of the InfoPackage name.) The InfoPackage name is followed by the job periodicity, and an indicator of whether the load is master data, transaction data, or a hierarchy (unless the nature of the data is clear from the name of the InfoPackage). The last three characters are a sequence number (which we may or may not retain over time). If any important feature of the InfoPackage (or InfoPackage Group) is changed before the job is started, add 1 to the sequence number. This will provide an audit trail on the daily job logs.

Examples:

Daily run of InfoPackage group “FI-PU-FM Tranx Data” BI_BTCH _ZBWFI_FI-PU-FM_TX____001Weekly run of InfoPackage group “FI-IO Master Data - Weekly” BI_BTCH _ZBWFI_FI-IO_MD_WEEK__001Weekly run of InfoPackage group “FI-IO Master Data - Weekly” BI_BTCH _ZBWFI_0FI-FM_IO_WEEK_001Note: In this example, we didn’t have room to include “MD,” but we still get the point across.

12.14 Variants

Definition:

When you create an InfoPackage or InfoPackage group, you must supply a variant name. Variants allow for subsequent processing for background jobs through triggering events. Variants are created through the AWB by selecting Tools Apply Attribute/Hierarchy Change Run.

Variant Naming:



Variant names start with ZBW, followed by the application area and then the periodicity of the InfoPackage group that listens for events using the variant.

Format:

ZBWa_DAY | MONTH | WEEK

Examples:

The variant for the FI daily attribute hierarchy load is:

ZBWFI_IO_DAY.

12.15 Events

Definition:

When you create an InfoPackage or InfoPackage group, you must supply the name of the event for which the variant associated with the InfoPackage is listening.

An event is a signal to background job controlling subsystem that a particular situation has arisen in the system. Events have meaning only in the background processing system and can be used only to start background jobs.Events are created using transaction SM62. Events can be triggered through the termination (successful or abnormal) of any job in the system.

Event Naming:

Event names start with ZBW, followed by the application area (a), whether the data is master data or attribute hierarchy maintenance, followed by the periodicity of the job.

Format: ZBWa_[MD | ATTR_HIER][DAILY | MONTH | WEEK]

ZBWFI_IO MD_DAILYZBWFI_ATTR_HEIR_CO_IO DAILY

An event chain is a series of several events that have been successfully completed independently of each other. If all the events contained in a chain been successfully executed, then a successful event is triggered. Otherwise, an unsuccessful event is triggered.

12.16 BW Query and Workbook Properties

Number format- Sign Display “(X)”- Suppress zeroes checked- Result position: Bottom/right

Display options- Adjust formatting after refreshing- Suppress repeated key values

BW Query Standard Characteristic Properties



- Result display: Suppress results row Conditional

BW Workbook StandardsAll workbooks should be imbedded into the standard workbook template. The template contains header and footer information to standardize printing format.

The template name is “Blank Template” and is located in the folder ‘Statewide Reporting’ in the BW

Development environment.

BW Workbook Standard Properties

Display- Adjust format after data refresh checked- Suppress repeated key values checked- Display filter cells for structures checked

Interaction- Enable interactive functions checked- Refresh query when opening workbook checked

Column width- Do not adjust column width checked

BW Workbook Formatting Standards

All BW workbooks created should use the standard template located in folder “BW Testing\Blank Template” (BW Development environment) to present a consistent look to workbook reports.

Additional text elements should be displayed to put the workbook report in context and provide useful information to others if the report is printed. The additional text elements should be located in column D (with the template embedding), starting in row 3 (with the template embedding), even with the top of the navigation block. The additional elements to be included are:

Relevance of the data (so a user knows when BW data was last updated).

Last refreshed (so a user knows if they are viewing current data).

Variables – text element only (so a user knows the selection parameters for the report).

Filters (so a user knows the “data restrictions” applied to the report).

13.0 Portals

This section provides a brief description of the various components in SAP Portal and the naming conventions that will be used for the VERIZON SCT project.

Delivered/imported objects such as roles and worksets are located in a specific namespace with a prefix namespace of com.sapportals*, com.sapportals.pct*, com.sap* and com.sap.pct*. These objects may not be modified. If the delivered objects are modified and a new version of the object is imported all changes or adjustments made in the customized version will be lost. If changes or adjustments need to be made to these objects the “Delta Link” principle should be used. To find out how to use this principle, refer to the SAP Portals Administration Guide.



13.1 iViews

Definition:

Integrated Views (iViews) are applications that enable the portal to access available information resources. The iViews return current information from such sources as relational databases, ERP systems, CRM systems, enterprise applications, collaboration tools, intranets, the World Wide Web, and email exchange systems. The information retrieved by iViews is displayed on the Pages of the Portal Content Area.

iView Naming:

The iView requires an iView Name and an iView ID. The iView ID is a unique name identifying the iView and may not include special characters. This ID is the technical name for the iView. The same iView ID cannot be assigned to more than one iView in the Portal content repository. If a variation of the iView is required the iView must be duplicated under a different iView ID becoming a new and independent entity. Standard SAP iViews received from iViewStudio will retain their ID’s and Names. If changes are required to a standard SAP iView create a copy of the iView renaming the name prefix of the iView ID (technical name) from com.sapportals to com.att. For custom iViews the iView ID’s name prefix should also be com.att with a suffix of the technical name providing a meaningful description of the iView.

The iView Name of duplicated or customized SAP standard iViews may be the same. The iView Name is the title of the iView that appears in the title bar of the portal as well as in any form, dialog box or window that displays a list of iViews. The iView Name contains alphanumeric characters.

Example:The Days Overdue Analysis iView delivered in the Business Package Customer Credit Management from iViewStudio requires changes. The standard iView com.sapportals.pct.crm.days_overdue_analysis will be duplicated and the technical name will be renamed to com.att.pct.crm.days_overdue_analysis. The changes will be made to com.att.pct.crm.days_overdue_analysis. The iView Name will remain Days Overdue Analysis

13.2 Channels

Definition:

Channels are the avenues in the SAP Enterprise Portal through which iViews are organized into meaningful categories of subjects or interests. Channels also are used to assign the content a user role has access to. An iView must be assigned to a Channel.

Channel Naming:

The Channel Name is the value that will appear in the Channel List of the iView Editor interface and the Channel Assignment interface. The name provided in this field should be a short description of the subject or interest category for the iViews.

The Channel Description allows for the entry of a long description of the Channel. When the Channel information has been saved, the Channel is created and an ID is automatically assigned in the system database.

Examples:



A Channel that contains iViews relating to Credit Management would have the Channel Name Credit Management iViews

A Channel containing iViews relating to VERIZON SCT news updates would have the Channel Name VERIZON SCT News

13.3 Roles

Definition:

A role is one of the central concepts of the SAP Enterprise Portal. It is a collection of tasks, services and information for a group of users. The role defines the contents the portal user may access and the actions he or she may perform. The role also defines the visualization of the contents and the navigation structure within SAP’s Enterprise Portal. A role contains varied information and combines everything the user will see on the Portal.

Role Naming:

The Role object name is a short description describing the role of the user or group of users who have been assign to the role. Also required to be entered is a Role ID which is the technical name of the role stored in the Portal Content Directory. The SAP Roles will be exported from the SAP R/3 system and imported to the Portal Roles.

13.4 Pages

Definition:

Pages within SAP’s Enterprise Portal provide the means to display the iViews and define the layout of the iViews in the content area of the portal.

Page Naming:

The Page requires a Page Name and a Page ID. The Page ID is a unique name that may include up to 40 characters including alphanumeric characters, underscores(_), dashes (-), dots (.) exclamation points (!), tildes(~) and parentheses. The Page ID may not include special characters or spaces. This ID is the technical name for the page. The Page Name is the title of the page and appears in the various user interfaces of the Portal. The Page Name may contain any character including spaces with the exception of apostrophes and quotation marks and may include up to 40 characters. The Page ID and Page Name will contain the same value and will provide a meaningful description describing the content of the iViews on the Page. The Page ID will also include underscores (_) to separate words.

Example:The Page Name for a page that contains iViews relating to Credit Management Reports would be Credit Management Reports and the Page ID would be Credit_Management_Reports

13.5 Workset

Definition:

Worksets allow services and pages to be grouped into folder hierarchies, like for roles. In contrast to roles, worksets are generic, re-usable structures or modules that can be added to roles. A workset alone cannot define a portal from the user point of view. A workset that is to be added to a Portal therefore is always part of a



role. By setting up a role or a number of roles from multiple worksets, the appearance of the Enterprise Portal is defined for the users.

Workset Naming:

The Workset object name is a short description describing the services and pages included in the workset. Also required to be entered is a Workset ID which is the technical name of the workset stored in the Portal Content Directory. The value of the ID may not include a period (.). The ID will contain the same value as the object name and will be prefixed by VERIZON SCT to identify the Workset as a VERIZON SCT workset in the Portal Content Directory. The Workset ID will also include underscores (_) to separate words.

Example:The Workset object name of the workset created to group the Accounts Receivable Clerk’s services and pages would be Acct Recv Clerk and the Workset ID would be VERIZON SCT _Acct_Recv_Clerk

13.6 External Services

Definition:

An External Service is a type of iView that cannot be assigned or directly linked to a Portal page. External Services are assigned to Portal users through role, directory or workset assignment and are usually displayed in the Portal as full-page iViews.

External Services Naming:

External Services requires a Name and an ID to be entered. The External Service ID is the technical name of the External Service. The External Service Name provides a short description of the content of the External Service. The External Service Name will be a meaningful description of the contents of what is being displayed in the portal view. The External Service ID will follow the same standards as all iViews and will be the same value as the Name with underscores separating the words.

Example:For an External Service displaying an analysis of open items sorted by due date for net payment the External Service would be Due Date Analysis. The technical id would be Due_Date_Analysis

13.7 Folders

Definition:

Roles and worksets are created by setting up folder hierarchies. Folders are also needed to define entry points within top-level navigation.

In contrast to a workset, a folder in a role is one that only belongs to this role and is set up within the role. A workset is a separate Portal Content Directory object in the form of a re-usable role component that can be added to one or more roles.

Folder Naming:

Folders are created in Roles and Worksets when the Role or Workset is created. The folder name will describe the content of the folder..

Example:



If the content of the folder is Accounts Receivable Clerk transactions, the name of the folder might be Acct Recv Clerk

14.0 Logical Paths and Files

All programs accessing files directly will be required to use logical filenames as part of their coding standard. During runtime the system and client used for execution replaces <SYSID> with system id and <MANDT> with client. As an example a program being run on system D10 client 088 would resolve to ..../D10/088/data.

The following code sample generates a physical filename using the SAP delivered function module FILE_GET_NAME. The parameter selection screen lists the full path as non-modifiable and the filename as modifiable. The following is sample code to produce the separate path and filename, with the intended display only attribute on the path field.*----------------------------------------------------------------------** SELECTION SCREEN LAYOUT **----------------------------------------------------------------------*PARAMETERS: FILEPATH LIKE RLGRAP-FILENAME, FILENAME LIKE RLGRAP-FILENAME OBLIGATORY DEFAULT 'testfile'.

*----------------------------------------------------------------------** VARIABLES **----------------------------------------------------------------------*DATA: PHYSNAME LIKE RLGRAP-FILENAME, PATHLENG TYPE I, NAMELENG TYPE I, PHYSLENG TYPE I, TEXT1(80) VALUE 'This is text1'.

*---------------------------------------------------------------** AT SELECTION SCREEN OUTPUT **---------------------------------------------------------------*AT SELECTION-SCREEN OUTPUT. PERFORM GET_FILENAME USING FILENAME PHYSNAME. NAMELENG = STRLEN( FILENAME ). PHYSLENG = STRLEN( PHYSNAME ). PATHLENG = PHYSLENG - NAMELENG. FILEPATH = PHYSNAME(PATHLENG). LOOP AT SCREEN. IF SCREEN-NAME EQ 'FILEPATH'. SCREEN-INPUT = '0'. MODIFY SCREEN. ENDIF. ENDLOOP.*----------------------------------------------------------------------** START-OF-SELECTION **----------------------------------------------------------------------*START-OF-SELECTION. CONCATENATE FILEPATH FILENAME INTO PHYSNAME.



*&---------------------------------------------------------------------**& Form GET_FILENAME*&---------------------------------------------------------------------** Obtains the physical file location using a function call.*----------------------------------------------------------------------** -->P_FILENAME file name* -->P_PHYSNAME full physical path*----------------------------------------------------------------------*form get_filename using p_filename p_physname. call function 'FILE_GET_NAME' exporting logical_filename = 'ZEX_STANDARD_FILENAME' parameter_1 = p_filename importing file_name = p_physname exceptions file_not_found = 1 others = 2. if sy-subrc <> 0. * e001(z1): Exception & occurred in function &. message e001(z1) with sy-subrc 'FILE_GET_NAME'. endif. endform. " GET_FILENAME

15.0 Standard Header Routine

The function module REPORT_HEADER subroutine is to be used to create standard heading lines for all customized ABAP/4 reports. The following steps indicate the process to follow to make use of this subroutine.

1. In the “attributes” section of your ABAP program, the “Title” should be the title of the report your ABAP/4 program is creating.

2. Code your REPORT statement with the NO STANDARD PAGE HEADING option:

REPORT ZEMR00lA NO STANDARD PAGE HEADING

LINE-SIZE 132

LINE-COUNT 65

MESSAGE-ID ZZ.

3. Additional documentation for using this function module can be found online in SAP.

16.0 Change and Transport System

16.1 Overview



The Transport Management System (TMS) will manage changes or additions to new and existing Data Dictionary objects, ABAP/4 programs, screens, CUA definitions and documentation.

TMS ensures that formal development work is registered and documented. The change system will help prevent parallel, uncoordinated changes to an object. For existing objects, the system ensures that only a single original copy of each object exists. Changes may normally be made only to the original copy. The change system also saves all corrections to ABAP/4 programs and Data Dictionary objects.

The transport system is used for moving objects from a development system to a production system. The transport system can perform several kinds of operations: overwrite components and data in a target system, delete and replace such objects, insert objects without overwriting existing ones, delete objects and also protect objects from being overwritten or deleted.

Client dependent objects should be in a separate request from client independent objects such as programs and tables. This will make it possible to distribute the client dependent objects to multiple clients.

Refer to Deliverable Transport Procedures for the details regarding VERIZON SCT transport procedures.

16.2 Creating a correction in the Development system

When creating a correction in the Development system, place the business area, application area, type of program and object id at the start of the description (e.g. PF_I999_) followed by the unique reference number assigned to the task being worked. It appears that when the list of correction numbers is generated, it cannot be easily sorted. This will make it easier to determine which change requests belong to each team and what they are for.

For example: PF_I999-0116 Price Book Interface for ..........

16.3 Promotion of ETL jobs to QA or Production

The ETL Transport Form is used to request that an ETL job or sequence (or a group of jobs and/or batches) be exported from one of the ETL environments and imported to the other. A form must be filled out completely and submitted to an ETL Administrator to complete your request whenever a change affects the ETL QA or Production environments. ETL developers will not have permissions to promote/demote ETL jobs, batches or scripts from or to the QA and/or Production ETL environments. When the ETL job (or other ETL object) is ready to be moved to the QA or Production projects, you must fill out the following “ETL Transport Request”
