Session ID CD 200 ABAP Objects Programming

Session ID: CD 200 ABAP Objects – Programming Guidelines

Introduction Fundamental and Formal Criteria Best Practices Administrative Issues

Learning Objectives As a result of this lecture, you will be able to: n A set of ABAP programming conventions that every ABAP programmer should use in new and ongoing ABAP development projects n These conventions govern: u General program layout and programming model u Some best practices and restrictions on the usage of language elements u Usage of test tools and other administrative issues ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 4

Introduction Fundamental and Formal Criteria Best Practices Administrative Issues

Introduction – Motivation Why ABAP Programming Guidelines? n ABAP Objects is a modern object oriented language providing all the features and possibilities known in object oriented development n Like in any other modern OO language there are often several ways to implement a specific solution for a given task, smart ones and not so smart ones n Additionally ABAP Objects offers special features, usually not available in other environments, to create especial performing, scalable and robust business applications n This lecture will give basic guidelines when and how to use the many possibilities ABAP Objects gives to business application developers ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 6

Introduction – Aim of the ABAP programming conventions is to support the development of: n correct n maintainable n well-structured n performing n readable n up-to-date n robust ABAP programs. The conventions cover formal as well as conceptual guide lines. ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 7

Introduction – Limitation It is not the aim of this lecture to provide a general programming guide containing generalities as: n KISS (Keep It Simple Stupid) n Simple is better than complex n Clear is better than cute n Save is better than insecure g Some overhead is unavoidable … ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 8

Introduction Fundamental and Formal Criteria Best Practices Administrative Issues

Fundamental Rules Formal Rules

Fundamental Rules – ABAP Objects Situation ABAP supports n An object oriented programming model based on classes and interfaces n A classical procedural programming model based on function modules, subroutines, dialog modules, and event blocks Rule The only programming model allowed is ABAP Objects n All coding must be implemented in global or local classes n Global or local interfaces are to be used when appropriate n Exceptions: u Reuse of services that are implemented in existing function modules u Implementation of new function modules, where technically necessary (usage of RFC or classical screens) See CD 158 and Appendix A ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 11

Fundamental Rules – Unicode-enabling Situation ABAP supports n Programs that are not Unicode-enabled n Programs that are Unicode-enabled (Unicode checks active). Rule Use Unicode-enabled programs only (Unicode checks active) n Static type checks specified more precisely n Byte and character strings processed separately n Structures handled appropriately for their type using structural equivalence rules n Uncontrolled memory manipulation no longer permitted See Appendix B ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 12

Fundamental Rules – GUI-Programming Situation ABAP offers n Classical Dynpros, selection screens, and lists n GUI controls n BSP n Web Dynpro ABAP Rule Web Dynpro ABAP is to be used for new projects where available. n BSP is an intermediate technology restricted to server pages. n Classical Dynpros (including Selection Screens) can be used where SAP GUI is involves. Usage of GUI Controls is recommended. n Use appropriate controls as Advanced List Viewer (ALV) instead of classical lists. n Separate application logic from presentation logic. ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 13

Fundamental Rules Formal Rules

Formal Rules – Program Attributes Situation When creating new programs, you must define the program attributes. Rules n Program Type: u Class pool/interface pool for global classes/interfaces u Function pool when technically necessary (Dynpro, RFC) u Subroutine pool for local classes u Executable program when technically necessary (background processing) n No linkage to a logical database n Unicode checks active n Fix point arithmetic set ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 15

Formal Rules – Processing Blocks Situation ABAP offers a variety of processing blocks to implement functionality. Rules n Procedures: u Implementation of new functionality in methods only u New function modules when technically necessary (Dynpro, RFC) u No new subroutines n Dialog modules for complex classical dynpros only n Event blocks u LOAD-OF-PROGRAM can be used as constructor of function groups u For selection screen events, see dialog modules u From reporting events implement only START-OF-SELECTION as entry point to a submitted program u No implementation of list events any more All allowed non-methods must serve as mere wrappers for a method call. ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 16

Formal Rules – Source Code Sequence Situation The definition of program parts is not fully regulated. n Arbitrary order of processing blocks n Declarative statements not limited to the head of a program or procedure n START-OF-SELECTION can be defined implicitly or several times Rules n Define an order: u Bottom up u Top down u Semantic proximity inside declaration parts n Local declarations must be done at the beginning of a procedure n No declarations in dialog modules or event blocks n START-OF-SELECTION must be defined explicitly ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 17

Formal Rules – Source Code Organization Situation The source code of a program can be organized with: n Include programs n Macros Rules n Include programs u Allowed for the source code modularization of exactly one ABAP program u No reuse for type definitions, declarations, or implementations u Must follow naming conventions of the ABAP Workbench u Strongly recommended for large programs (e. g. Top-Include) n Macros u Not ã allowed SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 18

Formal Rules – Coding Style Situation ABAP allows are large varieties of programming styles regarding e. g. : n Naming conventions n Indentation n Comments Rules n Use the Pretty Printer with settings that suit you most n Programs must be readable and understandable, use comments where necessary to fulfill that rule n No strict naming conventions for internal names, but to chose meaningful names that cannot be confused with predefined names n Respect the style of your colleagues Note: Pay attention for the hiding of external objects by internal objects. ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 19

Formal Rules – Modern ABAP Situation ABAP is an evolving language: n Each release new features and concepts are added to the language n Functional overlap with already existing language element occurs n You can decide which language element to use for a given purpose Rules n Always use the most appropriate language elements n Adjust old statements to new language elements if those that serve the same purpose better n Use the same language for the same purpose in different statements. Example: Use the keyword LENGTH len in type and data declarations with TYPES and DATA etc. instead of (len). The reason is to you use the same syntax in DATA and CREATE DATA. ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 20

Formal Rules – Correct ABAP Situation ABAP offers two types of static program checks: n Syntax check reporting errors and warnings n Extended program check reporting potential errors Rules n A program must be free from syntax warnings n A program must be free from all errors, warnings, and messages sent by the extended program check n For switching off the extended program check in special cases do not use SET EXTENDED CHECK OFF but specific pseudo comments ″#EC … ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 21

Introduction Fundamental and Formal Criteria Best Practices Administrative Issues

ABAP Objects, Modularization, and Program Flow Declarations Data Processing Data Storage and Retrieval Dynamic Programming Error Handling

Best Practices – ABAP Objects Situation Programming with classes and interfaces encompasses: n real model driven usage (UML-based programming) n simple procedural method calling (simply using methods) Rules n Don’t become a slave to academic OO paradigm n Use admitted and proven 4 GL-features of ABAP in classes n Use defensive programming, start always as restrictive as possible and ease the restrictions n Use local classes instead of private methods of global classes for internal modularization n Use inheritance moderately n For decoupling use events see CD 158 ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 24

Best Practices – Modularization Situation Functionality is modularized using methods. Rules n Short is better than long u Maximum number of lines should not surpass 50 lines and maximally 10 declarations (one method per page) n Modularize don’t atomize u No one line methods. Number of lines larger than seven. n Flat is better than deep u Reduce ã complexity, cyclomatic number smaller 10 SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 25

Best Practices – Parameter Interface Situation The parameter interface of a method is specified by: n Kind of parameters (IMPORTING, EXPORTING, CHANGING, RETURNING) n Number of parameters n Kind of parameter passing (by reference or by value) n Typing of parameters n Mandatory vs. optional parameters Rules n Use functional methods with no or only few importing parameters and one returning parameter n Create slim parameter interfaces n For the kind of parameter passing, weight performance vs. robustness. u Passing by reference is better in performance u Passing by value is more robust n For the typing of parameters, see generic programming n Make only those parameters mandatory for which alternating input is needed for each execution ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 26

Best Practices – Control structures Situation ABAP offers: n Branches (IF, CASE) n Loops (DO, WHILE, LOOP, PROVIDE, SELECT) Rules n Don’t allow undefined behavior in branches n Follow the SESE (Single-Entry/Single-Exit) principle n Avoid excessive block nesting depth (3 at maximum) n Do not use the statements CHECK or EXIT outside of loops n Do not use the statement LEAVE without additions ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 27

ABAP Objects, Modularization, and Program Flow Declarations Data Processing Data Storage and Retrieval Dynamic Programming Error Handling

Best Practices – Type Declarations Situation Data types can be declared n globally in the ABAP Dictionary, in Type Pools, and in global Classes or Interfaces n locally in programs, local classes and interfaces, and in procedures Rules n Do not create new type groups, use global classes or interfaces instead n Consider carefully, whether to declare global types in the ABAP Dictionary or in classes/interfaces n Reuse only global types that exactly match your needs n If the underlying built-in ABAP type is incomplete (c, n, p, x), favor standalone types over bound types. ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 29

Best Practices – Global Data Situation Each ABAP program has implicitly a global declaration part. Rules n Restrict global data objects declared in the global declaration part to those that are technically necessary n With ABAP Objects and without using logical databases, only classical dynpros need global data. n All other data must be declared in appropriate visibility sections of classes or as temporary working data in methods. ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 30

Best Practices – Declaration Syntax Situation There are still some syntax variants for declarations that should not be used any more. Rules n Do not use the TABLES statement besides declaring an interface to classical dynpros. Prepare for each dynpro a dedicated structure in the ABAP Dictionary n Favor TYPE over LIKE n Do not type field symbols with the addition STRUCTURE of statement FIELD-SYMBOLS. n Use only matching values behind VALUE in DATA, CONSTANTS etc. ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 31

ABAP Objects, Modularization, and Program Flow Declarations Data Processing Data Storage and Retrieval Dynamic Programming Error Handling

Best Practices – Usage of Data Objects Situation Data objects are treated according to their type. When the data type does not match the expected type of an operand position, in most cases the contents are converted to the expected type. Rules n Chose the data type of a data object that matches the expected values n Avoid overflow, use TRY in critical cases n Avoid unnecessary conversions n Avoid implicit casting n Use constants instead of numeric literals n Use text-symbols instead of text literals n Assign only valid values to data objects n For numerical values in character fields use a notation with the sign on the left and without spaces n Avoid accessing initial field symbols or reference variables ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 33

Best Practices – Byte and Character Processing Situation For byte and character processing ABAP offers text types and byte types and a set of statements n Text and byte fields have fixed, strings have variable length n Trailing blanks are ignored in most operand positions when assigning text fields and kept when assigning text strings n A structure containing only text fields can be handled as one text field Rules n Prefer strings versus text fields n Do not invent workarounds for existing language elements n Use FIND instead of SEARCH, use the new variant of REPLACE n Use regular expressions (as of Release 7. 0) instead of programming your own pattern searches and replacements n Use ALL OCCURRENCES in FIND and REPLACE instead of loops ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 34

Best Practices – Internal Tables Situation There are three kinds of internal tables: n Standard tables n Sorted tables n Hashed tables Rules n Use standard tables if they filled once, processed (sorted, read out) later and key access to table entries is not the central operation n Use sorted tables if you need a fast key access as well as an index access to table entries n Use hashed tables if key access to table entries is the central operation ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 35

Best Practices – System Fields Situation System fields are filled by the ABAP runtime environment. With exception of sy-repid, system fields are variables. Rules n Never write to system fields n Never use internal or obsolete system fields n Evaluate system fields directly behind the respective statements n Always evaluate sy-subrc, consider usage of ASSERT n Avoid usage of a system field in a statement that sets that system field n Do not use of system fields on the screen n Do not use system fields as actual parameters ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 36

ABAP Objects, Modularization, and Program Flow Declarations Data Processing Data Storage and Retrieval Dynamic Programming Error Handling

Best Practices – Persistent Data Situation Persistent data can be stored in several formats and in several media: n Relational database tables in the database n Data clusters in the database n Binary or text files on the application server or presentation server Rules n Storing data in relational database tables is always the first choice n Data clusters are appropriate for prepared data in non-relational format n Files can provide an interface to import or export data from or to non. ABAP systems n For reading data from database tables, do not use logical databases , you might use the Object Services Query instead (Release 7. 0) ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 38

Best Practices – Shared memory Situation An application server’s shared memory is used implicitly for program data and buffers and can be accessed explicitly using: n cross-transaction application buffers (EXPORT n shared objects (CREATE TO SHARED BUFFER|MEMORY) … AREA HANDLE) Rules n Use shared objects instead of shared buffers u You can store object structures with complex dependencies u You can work with shared objects data directly or via shared objects methods u The same memory is used simultaneously and copy-free by several users n Use shared objects either as a shared buffer or as an exclusive buffer; general shared memory programming involving many parallel read and write accesses is not supported by the locking mechanism n Access shared objects via wrapper classes n Do not use the obsolete contexts (CONTEXTS, SUPPLY, DEMAND) in the shared memory ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 39

ABAP Objects, Modularization, and Program Flow Declarations Data Processing Data Storage and Retrieval Dynamic Programming Error Handling

Best Practices – Generic Types Situation n ABAP offers a set of built-in generic types (any, any table, c, clike, csequence, data, hashed table, index table, n, numeric, object, p, simple, sorted table, standard table, x, xsequence) for the generic typing of field symbols and formal parameters of procedures n Typing defines how a field symbol or formal parameter can be used in operand positions n Field symbols or formal parameters receive their complete data type in the moment of binding Rules n Type formal parameters and field symbols appropriately u Match the needs of the implementation as well as the expectation of the user u Favor specific generic types, e. g. use csequence instead of any for text processing n The more general a field symbol or interface parameter is typed, the more careful you must be when using it ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 41

Best Practices – Dynamic Data Objects Situation Dynamic data objects are: n Data objects for which the memory consumption is not determined by the data type n Strings and internal tables n Deep data objects Rules n Avoid runtime errors due to memory overflow n Avoid runtime errors by accessing non-existing parts of dynamic objects n Avoid administrative overhead (each dynamic data object needs about 100 bytes for administration) ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 42

Best Practices – Field Symbols and References Situation ABAP offers pointers via field symbols and reference variables: n A field symbol is a symbolic name for a data object, to which you can assign actual memory areas at program runtime n A reference variable is a data object that contains a reference to a (data) object Rules n Use reference variables whenever field symbols are not necessary n Use field symbols only for u Generic access to data objects u Dynamic access to components of structures u Casting of data objects n Do not use field symbols if the only reason is to achieve dynamic offset/length programming ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 43

Best Practices – Dynamic Token Specification Situation ABAP allows you to specify tokens of many statements as the contents of data objects surrounded by parentheses. Rules n Never use dynamic token specification, where static specification is possible n Avoid runtime errors coming from wrong syntax or wrong names u Prepare correct patterns u Check the availability of addressed repository objects u Test such statements thoroughly u Handle all possible exceptions ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 44

Best Practices – Program Generation Situation Complete ABAP programs can be generated as: n Temporary subroutine pools n Programs of any type in the ABAP repository Rules n Program generation is restricted to experts n Use program generation only in cases where the other means of dynamic programming are not sufficient because of u performance issues u maintenance issues u security issues n Use RTTC instead of program generation for dynamic structures ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 45

ABAP Objects, Modularization, and Program Flow Declarations Data Processing Data Storage and Retrieval Dynamic Programming Error Handling

Error Handling – Exceptions Situation ABAP offers different ways to handle recoverable errors: n Class-based (new) exceptions n Classical (old) exceptions n Catchable runtime errors Rules n As of release 6. 10, define and throw only class-based exceptions n When you catch existing classical exceptions, map them to class based exceptions n Do not handle catchable runtime errors with CATCH SYSTEMEXCEPTIONS, use TRY … CATCH … ENDTRY only ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 47

Error Handling – Raising Exceptions Situation You can reuse or define exception classes. Rules 1. Check if an exception is appropriate u u If exception is too strong, use return values I exception is too weak, use assertions or exit messages 2. Describe the situation 3. Check for an existing exception class 4. Refine an existing exception class 5. Create a new exception class see CD 351 ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 48

Error Handling – Defining Exception Classes Situation Exception classes inherit from: n CX_STATIC_CHECK, propagated if explicitly declared, check by compiler n CX_DYNAMIC_CHECK, propagated if explicitly declared, check at runtime n CX_NO_CHECK, always propagated, no check Rules n Static check for exceptions a caller of a procedure explicitly must take care of n Dynamic check for exceptions a caller usually can avoid beforehand n No check for exceptions that describe errors that might occur anywhere and cannot be expected to be handled directly see CD 351 ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 49

Error Handling – Handling Exceptions Situation Class based exceptions are handled in a TRY – CATCH – CLEANUP – ENDTRY- construct. Rules n Catch and propagate exceptions selectively n Map low level exceptions to exceptions that are appropriate for the next level user during propagation n If necessary, do not forget to cleanup before propagating see CD 351 ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 50

Error Handling – Assertions Situation Assertions are available via the ASSERT statement: n If the condition is violated the program terminates with a runtime error, accesses the ABAP Debugger, or creates a log entry. n An Assertion is either always active or can be activated via maintenance transaction SAAB Rules n Use frequently assertions that can be activated n Do not use assertions where exceptions are required u Do not check conditions that are based on input parameters or the availability of some external resource with assertions u Check only preconditions for internally used functionality with assertions n Use assertions that are always active if checking s crucial see CD 351 ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 51

Error Handling – Messages Situation Messages are texts that are displayed using the MESSAGE statement: n In classical dynpro programming, messages provide an error dialog n In application programming messages can be used as a surrogate for exceptions that are combined with a text Rules n Use messages only for classical dynpro processing n Do not use messages – and in particular messages of type ‘E’ or ‘W’ – in other contexts than PAI processing n Do not use messages for exceptions u Catch existing ones and map them to class-based exceptions u For connecting exceptions with dialog texts implement the predefined interface IF_T 100_MESSAGE in the exception class n Use messages of type ‘X’ with extreme care only see CD 351 ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 52

Introduction Fundamental and Formal Criteria Best Practices Administrative Issues

Testing Documentation Packages

Administrative Issues – Testing Situation The ABAP development environment offers a great variety of test tools. Rules Cover 100 % of your coding by appropriate tests: n Perform bundled static checks with the Code Inspector n Cover your complete application coding with ABAP Unit tests n Cover your complete presentation coding with ECATT n Check the memory consumption with the Memory Inspector n Check the performance with the Performance and the Runtime Analysis n Check the program organization with the Coverage Analyzer ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 55

Testing Documentation Packages

Administrative Issues – Documentation Situation The ABAP Workbench offers a complete set of documentation tools for all kinds of repository objects. Rules All programs and program interfaces that are released for the usage by others must be documented: n Document global classes, function groups and function modules n If the name of an (public) component and its short text(s) are sufficient, you must not necessarily provide a long text for that component n If a class, the components of a class, or a program are described somewhere else (e. g. in the Knowledge Warehouse), you must link from the specific documentation to this documentation. ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 57

Testing Documentation Packages

Administrative Issues – Packages Situation Packages are containers of (closely related) repository objects with additional semantics: n Transport related properties n Access control for repository objects at design time n Nesting (layering) of packages Rules n Leverage all features of packages n Assign the application component as specific as possible n Define a package’s interface n Mark “Package check as server” n Care for strong cohesion of repository objects within a package and loose coupling between repository objects of different packages n Avoid the creation of objects in a package that isn’t original in the current system ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 59

Summary n Following some formal rules … n Utilizing some best practices … n Fulfilling some administrative issues … … results in State-of-the-Art ABAP ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 60

Questions? APPENDIX A – Stricter Syntax in ABAP Objects B – Stricter Syntax in Unicode Programs ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 61

Appendix A – Stricter Syntax in ABAP Objects (1/2) n Notation: No special characters in names, no length specifications <= zero, no multi-line literals n Declarations: LIKE references to data objects only; no implicit lengths or decimal places in TYPES; no length specifications for data types i, f, d, or t; no operational statements in structure definitions; FIELDS, RANGES, INFOTYPES, TABLES, NODES, COMMON PART, OCCURS, NON-LOCAL not permitted n Forbidden operations: CLEAR … WITH NULL, PACK, MOVE. . . PERCENTAGE, ADD-CORRESPONDING, DIVIDE-CORRESPONDING, SUBTRACTCORRESPONDING, MULTIPLY-CORRESPONDING, ADD THEN. . . UNTIL. . . , ADD FROM. . . TO. . . , CONVERT {DATE|INVERTED DATE} n String processing: Not permitted on numeric data objects n Field symbols: No implicit types; FIELD-SYMBOLS … STRUCTURE, ASSIGN. . . TYPE, ASSIGN LOCAL COPY OF, ASSIGN TABLE FIELD not permitted n Logic expressions: ><, => not permitted, table used with IN must be a selection table n Control structures: No operational statements between CASE and WHEN, ON-ENDON not permitted ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 62

Appendix A – Stricter Syntax in ABAP Objects (2/2) n Internal tables: No headers, no implicit work areas, no redundant key specifications, compatible work areas where necessary, obsolete READ variants and COLLECT. . . SORTED BY, WRITE TO itab, PROVIDE (short form) not permitted n Procedures (methods): No implicit type assignment, compatible initial values only, passing sy-subrc not permitted, raising undefined exceptions not permitted n Program calls: No joint use of USING and SKIP FIRST SCREEN when calling transactions, passing formal parameters implicitly in CALL DIALOG not permitted n Database accesses: No implicit work areas, no *-work areas, READ, LOOP, REFRESH FROM on database tables not permitted, VERSION addition to DELETE and MODIFY not permitted, no PERFORMING addition in Native SQL n Data cluster: No implicit identifiers, passing parameters explicitly not permitted, no implicit work areas, MAJOR-ID and MINOR-ID not permitted n Lists: DETAIL, SUMMARY, INPUT, MAXIMUM, MINIMUM, SUMMING, MARK, NEW-SECTION and obsolete print parameters not permitted ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 63

Appendix B – Stricter Syntax in Unicode Programs n Offset/length accesses: Only performed on character-type or byte-type ranges, and only on flat character-type initial parts of structures n Memory accesses: No access to memory outside a data object n Separation of byte string and character string processing: Explicit specification with IN BYTE MODE or IN CHARACTER MODE ; appropriate types expected – for character strings this means only c, d, n, t, string, and flat structures with purely character-type components n Structures: When assigning and comparing you must take the Unicode fragment view into consideration n File interface: Implicitly opening files not permitted; access, storage, and coding type must be specified explicitly; no write access to read-only files n Conversions: TRANSLATE. . . CODE PAGE. . . , TRANSLATE. . . NUMBER FORMAT. . . not permitted n OPEN SQL: Stricter conditions for work areas n Type assignment using STRUCTURE: Stricter checks on assignments to field symbols and formal parameters typed using STRUCTURE n Function module calls: A specified formal parameter of a function module must be available ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 64

Further Information è Public Web www. sap. com Net. Weaver Developer‘s Guide: www. sdn. sap. com/sdn/developersguide. sdn SAP Developer Network: http: //www. sdn. sap. com/sdn/developerareas/abap. sdn SAP Customer Services Network: www. sap. com/services/ è ABAP Keyword-Documentation Transaction ABAPHELP, always the first source of information è Articles in Journals http: //www. intelligenterp. com/feature/archive/heymann. shtml http: //www. intelligenterp. com/feature/archive/keller. shtml http: //www. sappublications. com/insider/article. htm? key=20248 Many ABAP articles at http: //www. sappro. com. upcoming nes ing Guideli Programm ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 65

Further Information è SAP Press Books ABAP Objects, Introduction: ISBN 0 -201 -75080 -5 (English), ISBN 3 -89842 -147 -3 (German) ABAP Reference: ISBN 1 -59229 -039 -6 (English), ISBN 3 -89842 -444 -8 (German) ABAP Quick Reference: ISBN 1 -59229 -057 -4 (English), ISBN 3 -89842 -680 -7 (German) for more books visit http: //www. sap-press. com, http: //www. sappress. de. # Net. Weaver Developer‘s Guide: www. sdn. sap. com/sdn/developersguide. sdn ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 66

Questions? Q&A ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 67

Feedback Please complete your session evaluation. Be courteous – deposit your trash, and do not take the handouts for the following session. Thank You ! ã SAP AG 2005, SAP Tech. Ed ’ 05 / CD 200 / 68