ท่านจะได้รับบริการที่ดี เป็นกันเอง และราคาไม่แพง
ตัวอย่างรายงาน
Report OEE
Report FI
Report Stock Card
ติดต่อ 0813942485 ศุภวัตร
วันพุธที่ 11 กันยายน พ.ศ. 2556
บริการ รับเขียน ABAP Report , ปรับปรุงระบบงานให้ดีขึ้น , BI Report
เรามีบริการ Support SAP ทั้งด้านเขียน ABAP และ BI Report ต่างๆ รวมถึงปรับปรุงระบบงานให้ดีขึ้น จากประสบการณ์กว่า 10 ปี ผ่านงานมาหลากหลายธุระกิจ
ติดต่อ 0813942485 ศุภวัตร
ติดต่อ 0813942485 ศุภวัตร
วันพุธที่ 10 ตุลาคม พ.ศ. 2550
MM CONFIGURATION TIPS
Maintain Plant
Plant 0001 is the SAP default.
OX14 - Define
Valuation Area (Tick one only- Once your system go live, no more
changes)
Most company take the SAP recommended choice - Value Material Stock at
Plant level
Value Material Stock at Plant or Company Level
- If you valuate material stocks at plant level,
the plant is the valuation area. - If you valuate material stocks at company code
level, the company code is the valuation area. - The decision you make applies to the whole
client.
OVXB - Create / Change / View Division
OX18 - Assign Plant to company code
e.g. 0001 - 0001 - All Plants
Px1 - Plant Px1
Px2 - Plant Px2
OX19 - Assignment of company code to the Controlling Area
OB38 - Assign company code to Credit Control Area
OMJ7 - Assign business area to Plant/Valuation area and division
e.g. Plant Px1 - Business Area Bx1 Bx2
Assign Valuation area to the Business Area
.e.g. Valuation area Vx1 - Business Area Bx1
Business Area Bx2
OMS0 - Assign Factory Calendar to the Plant and Business Area
The plant plays an important role in the following
areas:
- Material Valuation - If the valuation level is the
plant, the material stocks are valuated at plant level. Each plant can
have its own material prices and account determination. - Inventory Management - The material stocks are
managed within a plant. - MRP - Material requirements are planned for each
plant. Each plant has its own MRP data. Analyses for materials planning
can be made across plants. - Production - Each plant having they own
production/planning. - Costing - In costing, valuation prices are defined
only within a plant. - Plant Maintenance - If a plant performs plant
maintenance planning tasks, it is defined as a maintenance planning
plant. A maintenance planning plant can also carry out planning tasks
for other plants (maintenance plants).
costing and job-order costing, you must set valuation at plant
level.
The valuation level that you choose affects
- the maintenance of material master records
- the G/L accounts in which material stocks are
managed - the G/L accounts to which transactions are posted
in Materials Management
maintenance of material master records:
Depending on the valuation level chosen,
- you maintain accounting data in the material master
record for each plant or for each company code - you define a valuation price for the material in
each plant or in each company code
If material stocks are valuated at company code level,
all plant stocks of a material are managed in a joint stock account for
each company code.
If material stocks are valuated at plant level, you
can manage the material stocks for each plant in different accounts. For
each plant, you can define a separate determination.
If several plants
are to use account determination, you can group these plants in "Valuation
and Account Assignment" Customizing.
Material Master - Introduction
The material master is the starting point for the rest
of the modules.
What Material Types are there?
The material types that you use are configured in
Customizing for the Material Master under
Logistics Master Data :
Material Master -> Material -> Control data -> Define material
type attributes.
The following list shows you the material types
contained, for example, in the standard SAP R/3 System, and what their
different roles are:
DIEN (services)
Services are procured
externally and cannot be stored. A material master record of this material
type can always contain purchasing data.
FERT (finished products)
Finished
products are produced by the company itself. Since they cannot be ordered
by Purchasing, a material master record of this material type does not
contain purchasing data.
FHMI (production resources/tools)
Production resources/tools are procured
externally and used in the manufacture of products. A material master
record of this material type can contain purchasing data, but no sales
data. It is managed on a quantity basis. Examples of production
resources/tools are apparatus, equipment, and measuring and testing
devices.
HALB (semifinished products)
Semifinished products can be procured externally
(sub-contracting) as well as manufactured in-house. They are then
processed by the company. A material master record of this material type
can contain both purchasing and work scheduling data.
HAWA (trading goods)
Trading goods
are always procured externally and then sold. A material master record of
this material type can contain purchasing and sales data.
HIBE (operating supplies)
Operating
supplies are procured externally and required for the manufacture of other
products. A material master record of this material type can contain
purchasing data but no sales data.
NLAG (non-stock material)
Non-stock
material is material that is not held in stock because it is consumed
immediately. (Office supplies such as stationary. You need to create
purchase order and accounting document for payment but the stock balance
is always zero as it is issued out immediately to the various
department.)
ROH (raw materials)
Raw materials are
always procured externally and then processed. Since raw materials cannot
be sold, a material master record of this material type contains no sales
data.
UNBW (non-valuated materials)
Non-valuated materials are managed on a quantity
basis, but not by value.
VERP (packaging materials)
Packaging
materials are used to transport goods and come with the goods free of
charge. A material master record of this material type is managed both on
a quantity basis and by value.
WETT (competitive products)
Competitive products have their own material master
records created from the Basic Data view. The competitor's number, which
is stored in the material master record, assigns the material to a
particular competitor.
Maintain the Material Type
OMS2 - Material Type
Maintenance - Create/Change/Display
Steps:-
- transaction OMS2
- click Change
- key in the Material Type you want to change e.g.
FERT then hit enter
allows you to choose the Views for each Material Type.
(Press the
Page up/Page Down keys to scroll the
views)
If you tried to change from FERT to HAWA in 4.6x, you will receive an error message :-
The material type cannot be changed. This is not allowed if only external
procurement is defined for the new material type, or if the new material
type has a different account category reference than the old material
type.
To overcome it, goto OMS2 and change the HAWA material type.
In the Internal/external purchase orders sections:
Original Changes
Ext. purchase orders 2 1
Int. purchase orders 0 1
Screens in Material Master
- MM01 - Create, MM02 - Change, MM03 - Display and
MM06 - Flag for deletion. - MM04 - Display the changes done to the material
master. - MMAM - Change the Material Type. for e.g.
from FERT to HALB
Master Screen MM01 / MM02 / MM03
OMSR - Assign the field to the field group
OMS9 - Maintain the data screen field
Unit of Measure
In the material master, there is a Units of measure
button for users to store in the different conversion rate. This
sample program (ZUNT)
extract the data from the unit of measure conversion table.
In the Material Master the moving average price are
affected by:-
- Goods Receipt for Purchase Orders
- Transfer from Plant to Plant
- Invoice Receipt
- Settlement
- Price Change
- define new material group (OMSF)
- define new valuation class (OMSK) and automatic posting (OBYC)
- define new material account assignment group
(transaction OVK5) and Customer/Material/Account keys (transaction VKOA)
Block materials from inventory posting
After blocking, when the user do a inventory posting,
they will get this error message :-
E: Material xxxxx has status
Blocked for procmnt/whse
To activate the blocking :-
Goto transaction MM02 - Purchasing View
Type in 01 at the
MM/PP status field and save it
Create Delivery Log - Material xxx is blocked
During the Create Delivery (VL01), SAP prompt you a log that Material xxx is blocked.
During the Sales Order Create/Change for that
material, there might be some update termination that causes the
locked of the material (Windows hanged or power failure).
You can check using transaction SM12 - type an "*" at the User name field.
Check whether the material is in the locked list.
If it is in the locked list, asked the user to log out
before you delete it from the locked list.
Maintain Storage Location
MMSC - Collective entry of Storage Location for a material.
Insert new or delete un-used Storage Location.
Maintain whether the storage location was included or
excluded from MRP run.
Block Storage Location from further posting
1. You can block the storage location of a material
without affecting the rest of the location using the same
material.
Create a Physical Inventory document for
the storage location with transaction MI01
Select the Posting Block checkbox.
This would prevent transactions from
occuring until you either post or delete the physical inventory
document. (There are no impact, unless you do a post
difference for the physical inventory document.)
2. Another method is to rename the storage location name.
Go to transaction OX09
Edit -> Copy as
(copy the original storage location to a new name, replacing the first
character e.g. ZXXX)
Edit ->
Delete (delete the original storage location)
Do the reverse if you want back the original storage
location.
Accounting document number range for MM
Transaction OMW9
Document Type
Double click on desire transaction code to check the document type for
number range.
(e.g. MR21 Document type - PR)
Financial accounting document type
Assign the document type to a number range and account type.
(e.g. PR - Account type allowed for posting will be MS)
- Double click on the document type PR.
- Assign an unique starting number range that was not used. e.g. 88
- Choose the Account type for Material and G/L account (MS)
- The rest of the fields are optional (you can leave it as blank)
- A - Assets
- D - Customers
- K - Vendors
- M - Material
- S - G/L accounts
document type - Assign the number range to the running number range.
No. --> 88
Year (till) --> 9999
From number --> 8800000000
To number --> 8899999999
Current number -->Track by SAP
Ext (no tick internal or tick external) --> Blank
Accounting document will be generated if there are
stocks during price change, if you don't have any stocks, no accounting
document will be generated as there are no inventory to revaluate for
price differences.
Valuation Class for Material Group
In 4.6x and 4.5b,
you can assign valuation class to Material Group.
It is useful in the sense that user do not have to
manually do an Account Assignments.
For stock items, valuation class cannot be changed
whenever the stock on hand is not zero.
Valuation class are tied to a G/L account.
A change of valuation class means a change of G/L account.
In FI concept, you have to debit and credit to balance
the G/L account. That is why your stock must be zero before the
system allows you to changed the valuation class. If it is not zero,
you have to either transfer it to another material or do a dummy
issues. After changing the valuation class, do a reversal entries
for the stocks which you have transfer out or you have done a dummy
issues.
IMG - Material Management ->
Purchasing -> Material Master -> Entry aids for items without a
Material Master
G/L Accounts in MM Account Determination
The program RM07C030
check all the G/L account define in your Material Master valuation
class.
Search is via Company code and Valuation area.
Compare fields status for movement types
against General Ledger
Use SA38 then run RM07CUFA
Contributed by :- sapr3.tripod.com
About SAP
Founded in 1972 as Systems Applications and Products in Data Processing, SAP is the recognized leader in providing collaborative business solutions for all types of industries and for every major market.
From Walldorf to Wall Street: The SAP Success Story
Serving more than 41,200 customers worldwide, SAP is the world's largest business software company and the world's third-largest independent software provider overall. We have a rich history of innovation and growth that has made us a true industry leader. Today, SAP employs more than 41,900 people in more than 50 countries. Our professionals are dedicated to providing the highest level of customer service and support.
Knowledge, Experience, and Technology for Optimizing Business
SAP has leveraged our extensive experience to deliver a comprehensive range of solutions to empower every aspect of business operations. By using SAP solutions, organizations of all sizes – including small businesses and midsize companies– can reduce costs, improve performance, and gain the agility to respond to changing business needs.
SAP has also developed the SAP NetWeaver platform, which allows our customers to achieve more value from their IT investments.
Cross Application
From Walldorf to Wall Street: The SAP Success Story
Serving more than 41,200 customers worldwide, SAP is the world's largest business software company and the world's third-largest independent software provider overall. We have a rich history of innovation and growth that has made us a true industry leader. Today, SAP employs more than 41,900 people in more than 50 countries. Our professionals are dedicated to providing the highest level of customer service and support.
Knowledge, Experience, and Technology for Optimizing Business
SAP has leveraged our extensive experience to deliver a comprehensive range of solutions to empower every aspect of business operations. By using SAP solutions, organizations of all sizes – including small businesses and midsize companies– can reduce costs, improve performance, and gain the agility to respond to changing business needs.
SAP has also developed the SAP NetWeaver platform, which allows our customers to achieve more value from their IT investments.
Logistics
Material Management
Purchasing
Sales and Distribution Billing / Shipping / Pricing
Production Planning
Material Requirements Planning
Quality Management
Plant Maintenance
Project System
Financial
Accounting Financial
Account Receivable / Account Payable
Controlling
SAP HR
Human Resources
Cross Application
Business Information Warehouse
Advanced Planner and Optimizer
Basis Components
Locking / Authorization / Variants / Parameters / Unix / SAPGUI
Menu / Jobs / Spools / User Defaults / Transports / Statistics
Database Table
ABAP/4 Development
Workbench Abap/4 Query
Abap/4 Programming
Functions / SAP Script / ALV
Smartforms
CATT (Computer Aided Test Tool)
ABAP Workbench Certification
credit by : http://sapr3.tripod.com/index.htm
วันจันทร์ที่ 8 ตุลาคม พ.ศ. 2550
SAP ABAP4
ABAP (Advanced Business Application Programming) is a high level programming language created by the German software company SAP. It is currently positioned, alongside the more recently introduced Java, as the language for programming SAP's Web Application Server, part of its NetWeaver platform for building business applications. Its syntax is somewhat similar to COBOL.
History
ABAP is one of the many application-specific fourth-generation languages (4GLs) first developed in the 1980s. It was originally the report language for SAP R/2, a platform that enabled large corporations to build mainframe business applications for materials management and financial and management accounting. ABAP used to be an abbreviation of Allgemeiner Berichtsaufbereitungsprozessor, the German meaning of "generic report preparation processor", but was later renamed to Advanced Business Application Programming. ABAP was one of the first languages to include the concept of Logical Databases (LDBs), which provides a high level of abstraction from the basic database level.
The ABAP programming language was originally used by developers to develop the SAP R/3 platform. It was also intended to be used by SAP customers to enhance SAP applications – customers can develop custom reports and interfaces with ABAP programming. The language is fairly easy to learn for programmers but it is not a tool for direct use by non-programmers. Good programming skills, including knowledge of relational database design and preferably also of object-oriented concepts, are required to create ABAP programs.
ABAP remains the language for creating programs for the client-server R/3 system, which SAP first released in 1992. As computer hardware evolved through the 1990s, more and more of SAP's applications and systems were written in ABAP. By 2001, all but the most basic functions were written in ABAP. In 1999, SAP released an object-oriented extension to ABAP called ABAP Objects, along with R/3 release 4.6.
SAP's most recent development platform, NetWeaver, supports both ABAP and Java.
Implementation
Where does the ABAP program run?
All ABAP programs reside inside the SAP database. They are not stored in separate external files like Java or C++ programs. In the database all ABAP code exists in two forms: source code, which can be viewed and edited with the ABAP workbench, and "compiled" code ("generated" code is the more correct technical term), which is loaded and interpreted by the ABAP runtime system. Code generation happens implicitly when a unit of ABAP code is first invoked; it can also be requested explicitly, which is very useful in some situations, for example for mass regeneration of code after a release upgrade. If the source code is changed later or if one of the data objects accessed by the program has changed (e.g. fields were added to a database table), then the code is automatically regenerated.
ABAP programs run in the SAP application server, under control of the runtime system, which is part of the SAP kernel. The runtime system is responsible for processing ABAP statements, controlling the flow logic of screens and responding to events (such as a user clicking on a screen button). A key component of the ABAP runtime system is the Database Interface, which turns database-independent ABAP statements ("Open SQL") into statements understood by the underlying DBMS ("Native SQL"). The database interface handles all the communication with the relational database on behalf of ABAP programs; it also contains extra features such as buffering of frequently accessed data in the local memory of the application server.
SAP Basis
The ABAP language environment, including the syntax checking, code generation and runtime system, is part of the SAP Basis component. SAP Basis is the technological platform that supports the entire range of SAP applications, now typically implemented in the framework of the SAP Web Application Server. In that sense SAP Basis can be seen as the "operating system" on which SAP applications run. Like any operating system, SAP Basis contains both low-level services (for example memory management, database communication or servicing Web requests) and high-level tools for end users and administrators. These tools can be executables ("SAP kernel") running directly on the underlying operating system, transactions developed in ABAP, or Web-based interfaces.SAP Basis also provides a layer of abstraction between the business applications and the operating system and database. This ensures that applications do not depend directly upon a specific server or database platform and can easily be ported from one platform to another.
SAP Basis currently runs on UNIX (AIX, HP-UX, Solaris, Linux), Microsoft Windows, IBM Series i (former iSeries, AS/400) and IBM zSeries (former S/390). Supported databases are DB2, Informix, MaxDB, Oracle and Microsoft SQL Server (support for Informix was discontinued in SAP Basis release 7.00).
SAP systems and landscapes
All SAP data exists and all SAP software runs in the context of an SAP system. A system consists of a central relational database and one or more application servers ("instances") accessing the data and programs in this database. A SAP system contains at least one instance but may contain more, mostly for reasons of sizing and performance. In a system with multiple instances, load balancing mechanisms ensure that the load is spread evenly over the available application servers.Installations of the Web Application Server (landscapes) typically consist of three systems: one for development, one for testing and quality assurance, and one for production. The landscape may contain more systems, e.g. separate systems for unit testing and pre-production testing, or it may contain fewer, e.g. only development and production, without separate QA; nevertheless three is the most common configuration. ABAP programs are created and undergo first testing in the development system. Afterwards they are distributed to the other systems in the landscape. These actions take place under control of the Change and Transport System (CTS), which is responsible for concurrency control (e.g. preventing two developers from changing the same code at the same time), version management and deployment of programs on the QA and production systems.
The Web Application Server consists of three layers: the database layer, the application layer and the presentation layer. These layers may run on the same or on different physical machines. The database layer contains the relational database and the database software. The application layer contains the instance or instances of the system. All application processes, including the business transactions and the ABAP development, run on the application layer. The presentation layer handles the interaction with users of the system. Online access to ABAP application servers can go via a proprietary graphical interface, the SAPGUI, or via a Web browser.
Transactions
The normal way of executing ABAP code in the SAP system is by entering a transaction code. Transactions can be accessed via system-defined or user-specific, role-based menus. They can also be started by entering their transaction code (a mnemonic name of up to 20 characters) in the special command field, which is present in every SAP screen. Transactions can also be invoked programmatically by means of the ABAP statements CALL TRANSACTION and LEAVE TO TRANSACTION. Transaction codes can also be linked to screen elements or menu entries. Selecting such an element will start the transaction. The term "transaction" must not be misunderstood here: in the context just described, a transaction simply means calling and executing an ABAP program. In application programming, "transaction" often refers to an indivisible operation on data, which is either committed as a whole or undone (rolled back) as a whole. This concept exists in SAP but is there called a LUW (Logical Unit of Work). In the course of one transaction (program execution), there can be different LUWs.
Let’s have a look at the different kind of transactions:
Dialog transaction
These are the most common kind of transactions. The transaction code of a dialog transaction is linked to a Dynpro of an ABAP program. When the transaction is called, the respective program is loaded and the Dynpro is called. Therefore, a dialog transaction calls a Dynpro sequence rather than a program. Only during the execution of the Dynpro flow logic are the dialog modules of the ABAP program itself are called. The program flow can differ from execution to execution. You can even assign different dialog transaction codes to one program.
Parameter transaction
In the definition of a parameter transaction code, a dialog transaction is linked with parameters. When you call a parameter transaction, the input fields of the initial Dynpro screen of the dialog transaction are filled with parameters. The display of the initial screen can be inhibited by specifying all mandatory input fields as parameters of the transaction.
Variant transaction
In the definition of a variant transaction code, a dialog transaction is linked with a transaction variant. When a variant transaction is accessed, the dialog transaction is called and executed with the transaction variant. In transaction variants, you can assign default values to the input fields on several Dynpro screens in a transaction, change the attributes of screen elements, and hide entire screens. Transaction variants are maintained in transaction SHD0.
Report transaction
A report transaction is the transaction code wrapping for starting the reporting process. The transaction code of a report transaction must be linked with the selection screen of an executable program. When you execute a report transaction, the runtime environment internally executes the ABAP statement SUBMIT—more to come on that.
Transaction
A new kind of transaction as of release 6.10. The transaction code of an OO transaction is linked with a method of a local or global class. When the transaction is called, the corresponding program is loaded, for instance methods an object of the class is generated and the method is executed.
Types of ABAP programs
In ABAP, there are two different types of programs:
Report programs
A Sample Report
Report programs follow a relatively simple programming model whereby a user optionally enters a set of parameters (e.g. a selection over a subset of data) and the program then uses the input parameters to produce a report in the form of an interactive list. The output from the report program is interactive because it is not a passive display; instead it enables the user, through ABAP language constructs, to obtain a more detailed view on specific data records via drill-down functions, or to invoke further processing through menu commands, for instance to sort the data in a different way or to filter the data according to selection criteria. This method of presenting reports has great advantages for users who must deal with large quantities of information and must also have the ability to examine this information in highly flexible ways, without being constrained by the rigid formatting or unmanageable size of "listing-like" reports. The ease with which such interactive reports can be developed is one of the most striking features of the ABAP language.The term "report" is somewhat misleading in the sense that it is also possible to create report programs that modify the data in the underlying database instead of simply reading it.
A customized screen created using Screen Painter,which is one of the tools available in ABAP workbench(T-code = SE51).
Online programs
Online programs (also called module pools) do not produce lists. These programs define more complex patterns of user interaction using a collection of screens. The term “screen” refers to the actual, physical image that the users sees. Each screen also has a “flow logic”; this refers to the ABAP code invoked by the screens, i.e. the logic that initializes screens, responds to a user’s requests and controls the sequence between the screens of a module pool. Each screen has its own Flow Logic, which is divided into a "PBO" (Process Before Output) and "PAI" (Process After Input) section. In SAP documentation the term “dynpro” (dynamic program) refers to the combination of the screen and its Flow Logic.Online programs are not invoked directly by their name, but are associated with a transaction code. Users can then invoke them through customizable, role-dependent, transaction menus.
Apart from reports and online programs, it is also possible to develop sharable code units such as class libraries, function libraries and subroutine pools.
Subroutine pools
Subroutine pools, as the name implies, were created to contain collections of subroutines that can be called externally from other programs. Before release 6.10, this was the only way subroutine pools could be used. But besides subroutines, subroutine pools can also contain local classes and interfaces. As of release 6.10, you can connect transaction codes to methods. Therefore, you can now also call subroutine pools via transaction codes. This is the closest to a Java program you can get in ABAP: a subroutine pool with a class containing a method – say – main connected to a transaction code!
Function pools
Function pools, more commonly known as "function groups", are libraries of functions developed in ABAP. Functions differ from subroutines in that they are self-contained and do not belong to a specific program. ABAP functions accept as input any number of input parameters, return as output any number of output parameters, and raise exceptions if an error condition occurs.
Functions are invoked in ABAP programs by means of the CALL FUNCTION statement. A very important feature of ABAP is the ability to call function modules in another SAP system or in an external application using the RFC (Remote Function Call) mechanism. It is also possible to call functions asynchronously; the ABAP program then does not wait for the function to return but instead continues immediately, while the function executes in a separate context.
Type pools
Type pools are the precursors to general type definitions in the ABAP Dictionary. Before release 4.0, only elementary data types and flat structures could be defined in the ABAP Dictionary. All other types that should’ve been generally available had to be defined with TYPES in type pools. As of release 4.0, type pools were only necessary for constants. As of release 6.40, constants can be declared in the public sections of global classes and type pools can be replaced by global classes.
Class pools
Class pools serve as containers for exactly one global class. Besides the global class, they can contain global types and local classes/interfaces to be used in the global class. A class pool is loaded into memory by using one of its components. For example, a public method can be called from any ABAP program or via a transaction code connected to the method. You maintain class pools in the class builder.
Interface pools
Interface pools serve as containers for exactly one global interface—nothing more and nothing less. You use an interface pool by implementing its interface in classes and by creating reference variables with the type of its interface. You maintain interface pools in the class builder.
ABAP Workbench
The ABAP Workbench contains different tools for editing Repository objects. These tools provide you with a wide range of assistance that covers the entire software development cycle. The most important tools for creating and editing Repository objects are:ABAP Editor for writing and editing program codeABAP Dictionary for processing database table definitions and retrieving global typesMenu Painter for designing the user interface (menu bar, standard toolbar, application toolbar, function key assignment)Screen Painter for designing screens (dynamic programs) for user dialogsFunction Builder for displaying and processing function modules (routines with defined interfaces that are available throughout the system)Class Builder for displaying and processing ABAP Objects classes
The ABAP Dictionary
Enforces data integrity
Manages data definitions without redundancy
Is tightly integrated with the rest of the ABAP/4 Development Workbench.
Enforcing data integrity is the process of ensuring that data entered into the system is logical, complete, and consistent. When data integrity rules are defined in the ABAP/4 Dictionary, the system automatically prevents the entry of invalid data. Defining the data integrity rules at the dictionary level means they only have to be defined once, rather than in each program that accesses that data.The following are examples of data lacking integrity:A date field with a month value of 13An order assigned to a customer number that doesn’t existAn order not assigned to a customerManaging data definitions without redundancy is the process of linking similar information to the same data definition. For example, a customer database is likely to contain a customer’s ID number in several places. The ABAP Dictionary provides the capability of defining the characteristics of a customer ID number in only one place. That central definition then can be used for each instance of a customer ID number.The ABAP Dictionary’s integration with the rest of the development environment enables ABAP programs to automatically recognize the names and characteristics of dictionary objects.Additionally, the system provides easy navigation between development objects and dictionary definitions. For example, as a programmer, you can double-click on the name of a dictionary object in your program code, and the system will take you directly to the definition of that object in the ABAP/4 Dictionary.When a dictionary object is changed, a program that references the changed object will automatically reference the new version the next time the program runs. Because ABAP is interpreted, it is not necessary to recompile programs that reference changed dictionary objects.
ABAP syntax
This brief description of the ABAP syntax begins inevitably with the ubiquitous "Hello World" program.
"Hello World"PROGRAM TEST.
WRITE 'Hello World'.
This example contains two statements, one on each line. The keywords are PROGRAM and WRITE. The program displays a list on the screen. In this case, the list consists of the line "Hello World".
Formatting rules
ABAP has no format restrictions. You can enter statements in any format, so a statement can be indented, you can write several statements on one line, or spread a single statement over several lines. The only requirement is that every statement ends in a period.
You must separate words within a statement with at least one space. The system also interprets the end of line marker as a space.
The two-line "Hello World" program from above could also be written asPROGRAM TEST. WRITE 'Hello World' .
or even as: PROGRAM
TEST.
WRITE
'Hello World'.
Free formatting is convenient, but with complex code, such as deeply nested IF/ELSE blocks, it can get tricky. The ABAP editor therefore offers a "Pretty Printer" function, which can take care of proper indentation.
ABAP statements are not case-sensitive. The following code is perfectly permissible:proGRAm TEsT.
WriTe 'Hello World'.
Users can configure the way source text is presented (all upper case, all lower case, ABAP keywords in upper case and variable names in lower case, etc.) according to their own preference.
One obvious exception to the free-formatting rule are text literals. A text literal is a sequence of alphanumeric characters in the program code enclosed in single quotes. If a text literal in an ABAP statement extends across more than one line, then a ‘&’ character must be used to combine a succession of text literals into a single one. Example:USERPROMPT = 'Please double-click on a line in the output list ' &
'to see the complete details of the transaction.'.
Chained statements
The ABAP programming language allows you to concatenate consecutive statements with an identical first part into a chain statement.
To concatenate a sequence of separate statements, write the identical part only once and place a colon (:) after it. After the colon, write the remaining parts of the individual statements, separating them with commas. Ensure that you place a period (.) after the last part to inform the system where the chain ends.
Chaining is very often used in WRITE statements. WRITE accepts just one argument, so if for instance you wanted to display three fields from a structure called FLIGHTINFO, you would have to code:WRITE FLIGHTINFO-CITYFROM.
WRITE FLIGHTINFO-CITYTO.
WRITE FLIGHTINFO-AIRPTO.
Chaining the statements results in a more readable and more intuitive form:WRITE: FLIGHTINFO-CITYFROM, FLIGHTINFO-CITYTO, FLIGHTINFO-AIRPTO.
In the chain, a colon separates the beginning of the statement from the variable parts. After the colon or commas, you can insert any number of spaces.
You could, for example, write the same statement like this:WRITE: FLIGHTINFO-CITYFROM,
FLIGHTINFO-CITYTO,
FLIGHTINFO-AIRPTO.
In a chain statement, the first part (before the colon) is not limited to the keyword of the statements. For example, the codeSUM = SUM + 1.
SUM = SUM + 2.
SUM = SUM + 3.
SUM = SUM + 4.
could be written in chained form:SUM = SUM + : 1, 2, 3, 4.
Comments
Comments are texts that you can write between the statements of your ABAP program to explain their purpose to a reader. ABAP has two ways to write a comment: by placing an asterisk "*" in the leftmost comumn the entire line becomes a comment (the ABAP editor will show these lines in a different color). Inside a line of code, anything to the right of a double quotation mark is also treated as a comment:***************************************
** Program: BOOKINGS **
** Author: Joe Byte, 07-Jul-2007 **
***************************************
REPORT BOOKINGS.
* Read flight bookings from the database
SELECT * FROM FLIGHTINFO
WHERE CLASS = 'Y' "Y = economy
OR CLASS = 'C'. "C = business
(...)
DATA and TYPES
It is a special strength of ABAP that you can define a great variety of data types and objects that span the spectrum from very elementary data types to very complex and dynamic types. Consequently, the subject of ABAP declarations is quite extensive.
ABAP accepts all data types defined in the SAP dictionary or in Type Pools. Types can also be defined inside the program itself. Object variables take the type of their class. Like many other programming languages, ABAP has a set of "primitive" types. These can be binary numeric (I for integer, F for floating point), packed decimal (P), character (C or N, where the N type is used for numeric strings that can be used in computation) or hexadecimal (X). Date fields (type D) and time fields (type T) have a "dual" nature; in an input/output context they behave like strings, but in a computational context they are numeric integers. This makes date and time calculations extremely easy. For example:DATESENT = '20070901'.
VALIDTO = DATESENT + 60.
WRITE: 'Offer is valid until', VALIDTO DD/MM/YYYY.
In this example, a string literal representing September 1, 2007is assigned to DATESENT. DATESENT is then used in a numeric calculation to produce another data field, VALIDTO. VALIDTO is then output as a string. The optional "DD/MM/YYYY" modifier displays the date in a predefined nformat, here "31/10/2007". Without the modifier the date would display as "20071031".
Data and Types
All ABAP variables must be declared before they are used. The declaration consists of the name, type, length (where applicable), additional modifiers (e.g. the number of implied decimals for a packed decimal field) and optionally an initial value:* Primitive types:
DATA: COUNTER TYPE I,
VALIDITY TYPE I VALUE 60,
TAXRATE(3) TYPE P DECIMALS 1,
LASTNAME(20) TYPE C.* Dictionary types:
DATA: ORIGIN TYPE COUNTRY.* Internal table:
DATA: T_FLIGHTS TYPE TABLE OF FLIGHTINFO,
T_LOOKUP TYPE HASHED TABLE OF FLT_LOOKUP.* Objects:
DATA: BOOKING TYPE REF TO CL_FLT_BOOKING.
Notice the use of the colon to chain together consecutive DATA statements.
ABAP OBJECTS
Object orientation in ABAP is an extension of the ABAP language that makes available the advantages of object-oriented programming, such as encapsulation, interfaces, and inheritance. This helps to simplify applications and make them more controllable.
ABAP Objects is fully compatible with the existing language, so you can use existing statements and modularization units in programs that use ABAP Objects, and can also use ABAP Objects in existing ABAP programs.
ABAP Statements – an Overview
The first element of an ABAP statement is the ABAP keyword. This determines the category of the statement. The different statement categories are as follows:
Declarative Statements
These statements define data types or declare data objects which are used by the other statements in a program or routine. The collected declarative statements in a program or routine make up its declaration part.
Examples of declarative keywords:
TYPES, DATA, TABLES
Modularization Statements
These statements define the processing blocks in an ABAP program.
The modularization keywords can be further divided into:
· Event Keywords
You use statements containing these keywords to define event blocks. There are no special statements to conclude processing blocks - they end when the next processing block is introduced.
Examples of event keywords are:
AT SELECTION SCREEN, START-OF-SELECTION, AT USER-COMMAND
· Defining keywords
You use statements containing these keywords to define subroutines, function modules, dialog modules and methods. You conclude these processing blocks using the END- statements.
Examples of definitive keywords:
FORM ..... ENDFORM, FUNCTION ... ENDFUNCTION, MODULE ... ENDMODULE.
Control Statements
You use these statements to control the flow of an ABAP program within a processing block according to certain conditions.
Examples of control keywords:
IF, WHILE, CASE
Call Statements
You use these statements to call processing blocks that you have already defined using modularization statements. The blocks you call can either be in the same ABAP program or in a different program.
Examples of call keywords:
CALL METHOD, CALL TRANSACTION, SUBMIT, LEAVE TO
Operational Statements
These keywords process the data that you have defined using declarative statements.
Examples of operational keywords:
MOVE, ADD
Unique Concept of Internal Table in ABAP
Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data objects, they save the programmer the task of dynamic memory management in his or her programs. You should use internal tables whenever you want to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for storing and formatting data from a database table within a program. They are also a good way of including very complicated data structures in an ABAP program.
Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects A data type is the abstract description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The data type is also an attribute of an existing data object.
Internal Tables as Data Types
Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type, key, and table type.
Line type
The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the structure is a column in the internal table. However, the line type may also be elementary or another internal table.
Line Type can also refer to an ABAP Object's reference pointer value. If two ABAP Objects are not related, they do not have the same line type. The line type is stored in the value of the reference pointer and can be viewed in the debugger. If one object attempts to access another unrelated object's components, you will receive an error specifying that the line types do not match.
Key
The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify whether the key should be UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries. The uniqueness depends on the table access method.
If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves internal tables. If a table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type is an internal table, the default key is empty.
The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. Internal tables with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember this, for example, if you intend to sort the table according to the key.
Table type
The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table. The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled very quickly, since the system does not have to check whether there are already existing entries.
Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.
Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique. When you define the table, you must specify the key as UNIQUE.
Generic Internal Tables
Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic internal tables to specify the types of field symbols and the interface parameters of procedures. You cannot use them to declare data objects.
Internal Tables as Dynamic Data Objects
Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects, since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration) is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the internal table.
Choosing a Table Type
The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most frequently executed.
Standard tables
This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key access, the response time is logarithmically proportional to the number of table entries.
Sorted tables
This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the table key in the WHERE condition.
Hashed tables
This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data.
Advanced Topics
Batch Input: Concepts
Processing Sessions
The above figure shows how a batch input session works.
A batch input session is a set of one or more calls to transactions along with the data to be processed by the transactions. The system normally executes the transactions in a session non-interactively, allowing rapid entry of bulk data into an R/3 System.
A session records transactions and data in a special format that can be interpreted by the R/3 System. When the System reads a session, it uses the data in the session to simulate on-line entry of transactions and data. The System can call transactions and enter data using most of the facilities that are available to interactive users.
For example, the data that a session enters into transaction screens is subject to the same consistency checking as in normal interactive operation. Further, batch input sessions are subject to the user-based authorization checking that is performed by the system.
Advantages of ABAP over Contemporary languages
ABAP Objects offers a number of advantages, even if you want to continue using procedural programming. If you want to use new ABAP features, you have to use object-oriented interfaces anyway.
Sharing Data: With ABAP shared objects, you can aggregate data once at a central location and the different users and programs can then access this data without the need for copying.
Exception Handling: With the class-based exception concept of ABAP, you can define a special control flow for a specific error situation and provide the user with information about the error.
Developing Persistency: For permanent storage of data in ABAP, you use relational database tables by means of database-independent Open SQL, which is integrated in ABAP. However, you can also store selected objects transparently or access the integrated database or other databases using proprietary SQL.
Connectivity and Interoperability: The Exchange Infrastructure and Web services are the means by which developers can implement a service-oriented architecture. With Web services, you can provide and consume services independently of implementation or protocol. Furthermore, you can do so within NetWeaver and in the communication with other systems. With the features of the Exchange Infrastructure, you can enable, manage, and adapt integration scenarios between systems.
Making Enhancements: With the Enhancement Framework, you can enhance programs, function modules, and global classes without modification as well as replace existing code. The Switch Framework enables you activate only specific development objects or enhancements in a system.
Considerable Aspects
It follows a list of aspects to be considered during development. The list of course is not complete.
Dynpro persistence
When implementing dynpros one has to care for himself to read out and persist the necessary fields. Recently it happened to me that I forgot to include a field into the UPDATE-clause which is an error not so easy to uncover if you have other problems to be solved in the same package. Here, tool-support or built-in mechanisms would help.
The developer could help himself out by creating something like a document containing a cookbook or guide in which parts of a dynpro logic one has to care about persistence. With that at hand, it would be quite easy finding those bugs in short time. Maybe a report scanning for the definition of the dynpro fields to be persisted could scan the code automatically, too.
Memory Cache
It should be common-sense that avoiding select-statements onto the database helps reducing the server load. For that the programmer either can resort to function modules if available. This maybe is the case for important tables. Or the programmer needs to implement his own logic using internal tables. Here, the standard software package could provide the developer with a tool or a mechanism auto-generating memory cached tables resp. function modules implementing this.
Sometimes buffering of database tables could be used, if applicable. But that would require an effort in customizing the system and could drain down system performance overall, especially if a table is involved that has a central role.
Interfaces
It should be noticed that some function modules available have an incomplete interface. That means, the interface does not include all parameters evaluated by the logic of the function module. For example, global variables from within the function group could be read out, which cannot be influenced by the general caller. Or memory parameters are used internally to feed the logic with further information.
One workaround here would be copying the relevant parts of the logic to a newly created function module and then adapt it to the own context. This sometimes is possible, maybe if the copied code is not too lengthy and only a few or no calls to other logic is part of it.
A modification of the SAP code could be considered, if the modification itself is unavoidable (or another solution would be not justifiable by estimated effort to spend on it) and if the location of the modification seems quite safe against future upgrades or hot fixes. The latter is something that could be evaluated by contacting the SAP hotline or working with OSS message (searching thru existing one, perhaps open a new one).
Example
'From SAP NetWeaver:'*-----------
* set an exclusive lock at level object-type & object-id
*------------------------------------------
IF NOT lf_bapi_error = true.
IF ( NOT istourhd-doc_type IS INITIAL ) AND
( NOT istourhd-doc_id IS INITIAL )
CALL FUNCTION 'ENQUEUE_/DSD/E_HH_RAREF'
EXPORTING
obj_typ = istourhd-doc_type
obj_id = istourhd-doc_id
EXCEPTIONS
foreign_lock = 1
system_failure = 2
OTHERS = 3.
IF sy-subrc <> 0.
* terminate processing...
lf_bapi_error = true.—
* ...and add message to return table
PERFORM set_msg_to_bapiret2
USING sy-msgid gc_abort sy-msgno
sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4
gc_istourhd gc_enqueue_refdoc space
CHANGING lt_return.
ENDIF.
ENDIF.
ENDIF. "
Example Report(Type - ALV(ABAP List Viewer))REPORT Z_ALV_SIMPLE_EXAMPLE_WITH_ITAB .
************************************************************************
*Simple example to use ALV and to define the ALV data in an internal
*table
************************************************************************
*data definition
tables:
marav. "Table MARA and table MAKT
*---------------------------------------------------------------------*
* Data to be displayed in ALV
* Using the following syntax, REUSE_ALV_FIELDCATALOG_MERGE can auto-
* matically determine the fieldstructure from this source program
Data:
begin of imat occurs 100,
matnr like marav-matnr, "Material number
maktx like marav-maktx, "Material short text
matkl like marav-matkl, "Material group (so you can test to make
" intermediate sums)
ntgew like marav-ntgew, "Net weight, numeric field (so you can test to
"make sums)
gewei like marav-gewei, "weight unit (just to be complete)
end of imat.
*---------------------------------------------------------------------*
* Other data needed
* field to store report name
data i_repid like sy-repid.
* field to check table length
data i_lines like sy-tabix.
*---------------------------------------------------------------------*
* Data for ALV display
TYPE-POOLS: SLIS.
data int_fcat type SLIS_T_FIELDCAT_ALV.
*---------------------------------------------------------------------*
select-options:
s_matnr for marav-matnr matchcode object MAT1.
*---------------------------------------------------------------------*
start-of-selection.
* read data into table imat
select * from marav
into corresponding fields of table imat
where
matnr in s_matnr.
* Check if material was found
clear i_lines.
describe table imat lines i_lines.
if i_lines lt 1.
* Using hardcoded write here for easy upload
write: /
'No materials found.'.
exit.
endif.
end-of-selection.
* To use ALV, we need a DDIC-structure or a thing called Fieldcatalogue.
* The fieldcatalouge can be generated by FUNCTION
* 'REUSE_ALV_FIELDCATALOG_MERGE' from an internal table from any
* report source, including this report.
*---------------------------------------------------------------------*
* Store report name
i_repid = sy-repid.
* Create Fieldcatalogue from internal table
CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE'
EXPORTING
I_PROGRAM_NAME = i_repid
I_INTERNAL_TABNAME = 'IMAT' "capital letters!
I_INCLNAME = i_repid
CHANGING
CT_FIELDCAT = int_fcat
EXCEPTIONS
INCONSISTENT_INTERFACE = 1
PROGRAM_ERROR = 2
OTHERS = 3.
*explanations:
* I_PROGRAM_NAME is the program which calls this function
*
* I_INTERNAL_TABNAME is the name of the internal table which you want
* to display in ALV
*
* I_INCLNAME is the ABAP-source where the internal table is defined
* (DATA....)
* CT_FIELDCAT contains the Fieldcatalouge that we need later for
* ALV display
IF SY-SUBRC <> 0.
write: /
'Returncode',
sy-subrc,
'from FUNCTION REUSE_ALV_FIELDCATALOG_MERGE'.
ENDIF.
*This was the fieldcatlogue
*---------------------------------------------------------------------*
*
* Call for ALV list display
CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY'
EXPORTING
I_CALLBACK_PROGRAM = i_repid
IT_FIELDCAT = int_fcat
TABLES
T_OUTTAB = imat
EXCEPTIONS
PROGRAM_ERROR = 1
OTHERS = 2.
*explanations:
* I_CALLBACK_PROGRAM is the program which calls this function
*
* IT_FIELDCAT (just made by REUSE_ALV_FIELDCATALOG_MERGE) contains
* now the data definition needed for display
*
* I_SAVE allows the user to save his own layouts
*
* T_OUTTAB contains the data to be displayed in ALV
IF SY-SUBRC <> 0.
write: /
'Returncode',
sy-subrc,
'from FUNCTION REUSE_ALV_LIST_DISPLAY'.
ENDIF.
History
ABAP is one of the many application-specific fourth-generation languages (4GLs) first developed in the 1980s. It was originally the report language for SAP R/2, a platform that enabled large corporations to build mainframe business applications for materials management and financial and management accounting. ABAP used to be an abbreviation of Allgemeiner Berichtsaufbereitungsprozessor, the German meaning of "generic report preparation processor", but was later renamed to Advanced Business Application Programming. ABAP was one of the first languages to include the concept of Logical Databases (LDBs), which provides a high level of abstraction from the basic database level.
The ABAP programming language was originally used by developers to develop the SAP R/3 platform. It was also intended to be used by SAP customers to enhance SAP applications – customers can develop custom reports and interfaces with ABAP programming. The language is fairly easy to learn for programmers but it is not a tool for direct use by non-programmers. Good programming skills, including knowledge of relational database design and preferably also of object-oriented concepts, are required to create ABAP programs.
ABAP remains the language for creating programs for the client-server R/3 system, which SAP first released in 1992. As computer hardware evolved through the 1990s, more and more of SAP's applications and systems were written in ABAP. By 2001, all but the most basic functions were written in ABAP. In 1999, SAP released an object-oriented extension to ABAP called ABAP Objects, along with R/3 release 4.6.
SAP's most recent development platform, NetWeaver, supports both ABAP and Java.
Implementation
Where does the ABAP program run?
All ABAP programs reside inside the SAP database. They are not stored in separate external files like Java or C++ programs. In the database all ABAP code exists in two forms: source code, which can be viewed and edited with the ABAP workbench, and "compiled" code ("generated" code is the more correct technical term), which is loaded and interpreted by the ABAP runtime system. Code generation happens implicitly when a unit of ABAP code is first invoked; it can also be requested explicitly, which is very useful in some situations, for example for mass regeneration of code after a release upgrade. If the source code is changed later or if one of the data objects accessed by the program has changed (e.g. fields were added to a database table), then the code is automatically regenerated.
ABAP programs run in the SAP application server, under control of the runtime system, which is part of the SAP kernel. The runtime system is responsible for processing ABAP statements, controlling the flow logic of screens and responding to events (such as a user clicking on a screen button). A key component of the ABAP runtime system is the Database Interface, which turns database-independent ABAP statements ("Open SQL") into statements understood by the underlying DBMS ("Native SQL"). The database interface handles all the communication with the relational database on behalf of ABAP programs; it also contains extra features such as buffering of frequently accessed data in the local memory of the application server.
SAP Basis
The ABAP language environment, including the syntax checking, code generation and runtime system, is part of the SAP Basis component. SAP Basis is the technological platform that supports the entire range of SAP applications, now typically implemented in the framework of the SAP Web Application Server. In that sense SAP Basis can be seen as the "operating system" on which SAP applications run. Like any operating system, SAP Basis contains both low-level services (for example memory management, database communication or servicing Web requests) and high-level tools for end users and administrators. These tools can be executables ("SAP kernel") running directly on the underlying operating system, transactions developed in ABAP, or Web-based interfaces.SAP Basis also provides a layer of abstraction between the business applications and the operating system and database. This ensures that applications do not depend directly upon a specific server or database platform and can easily be ported from one platform to another.
SAP Basis currently runs on UNIX (AIX, HP-UX, Solaris, Linux), Microsoft Windows, IBM Series i (former iSeries, AS/400) and IBM zSeries (former S/390). Supported databases are DB2, Informix, MaxDB, Oracle and Microsoft SQL Server (support for Informix was discontinued in SAP Basis release 7.00).
SAP systems and landscapes
All SAP data exists and all SAP software runs in the context of an SAP system. A system consists of a central relational database and one or more application servers ("instances") accessing the data and programs in this database. A SAP system contains at least one instance but may contain more, mostly for reasons of sizing and performance. In a system with multiple instances, load balancing mechanisms ensure that the load is spread evenly over the available application servers.Installations of the Web Application Server (landscapes) typically consist of three systems: one for development, one for testing and quality assurance, and one for production. The landscape may contain more systems, e.g. separate systems for unit testing and pre-production testing, or it may contain fewer, e.g. only development and production, without separate QA; nevertheless three is the most common configuration. ABAP programs are created and undergo first testing in the development system. Afterwards they are distributed to the other systems in the landscape. These actions take place under control of the Change and Transport System (CTS), which is responsible for concurrency control (e.g. preventing two developers from changing the same code at the same time), version management and deployment of programs on the QA and production systems.
The Web Application Server consists of three layers: the database layer, the application layer and the presentation layer. These layers may run on the same or on different physical machines. The database layer contains the relational database and the database software. The application layer contains the instance or instances of the system. All application processes, including the business transactions and the ABAP development, run on the application layer. The presentation layer handles the interaction with users of the system. Online access to ABAP application servers can go via a proprietary graphical interface, the SAPGUI, or via a Web browser.
Transactions
The normal way of executing ABAP code in the SAP system is by entering a transaction code. Transactions can be accessed via system-defined or user-specific, role-based menus. They can also be started by entering their transaction code (a mnemonic name of up to 20 characters) in the special command field, which is present in every SAP screen. Transactions can also be invoked programmatically by means of the ABAP statements CALL TRANSACTION and LEAVE TO TRANSACTION. Transaction codes can also be linked to screen elements or menu entries. Selecting such an element will start the transaction. The term "transaction" must not be misunderstood here: in the context just described, a transaction simply means calling and executing an ABAP program. In application programming, "transaction" often refers to an indivisible operation on data, which is either committed as a whole or undone (rolled back) as a whole. This concept exists in SAP but is there called a LUW (Logical Unit of Work). In the course of one transaction (program execution), there can be different LUWs.
Let’s have a look at the different kind of transactions:
Dialog transaction
These are the most common kind of transactions. The transaction code of a dialog transaction is linked to a Dynpro of an ABAP program. When the transaction is called, the respective program is loaded and the Dynpro is called. Therefore, a dialog transaction calls a Dynpro sequence rather than a program. Only during the execution of the Dynpro flow logic are the dialog modules of the ABAP program itself are called. The program flow can differ from execution to execution. You can even assign different dialog transaction codes to one program.
Parameter transaction
In the definition of a parameter transaction code, a dialog transaction is linked with parameters. When you call a parameter transaction, the input fields of the initial Dynpro screen of the dialog transaction are filled with parameters. The display of the initial screen can be inhibited by specifying all mandatory input fields as parameters of the transaction.
Variant transaction
In the definition of a variant transaction code, a dialog transaction is linked with a transaction variant. When a variant transaction is accessed, the dialog transaction is called and executed with the transaction variant. In transaction variants, you can assign default values to the input fields on several Dynpro screens in a transaction, change the attributes of screen elements, and hide entire screens. Transaction variants are maintained in transaction SHD0.
Report transaction
A report transaction is the transaction code wrapping for starting the reporting process. The transaction code of a report transaction must be linked with the selection screen of an executable program. When you execute a report transaction, the runtime environment internally executes the ABAP statement SUBMIT—more to come on that.
Transaction
A new kind of transaction as of release 6.10. The transaction code of an OO transaction is linked with a method of a local or global class. When the transaction is called, the corresponding program is loaded, for instance methods an object of the class is generated and the method is executed.
Types of ABAP programs
In ABAP, there are two different types of programs:
Report programs
A Sample Report
Report programs follow a relatively simple programming model whereby a user optionally enters a set of parameters (e.g. a selection over a subset of data) and the program then uses the input parameters to produce a report in the form of an interactive list. The output from the report program is interactive because it is not a passive display; instead it enables the user, through ABAP language constructs, to obtain a more detailed view on specific data records via drill-down functions, or to invoke further processing through menu commands, for instance to sort the data in a different way or to filter the data according to selection criteria. This method of presenting reports has great advantages for users who must deal with large quantities of information and must also have the ability to examine this information in highly flexible ways, without being constrained by the rigid formatting or unmanageable size of "listing-like" reports. The ease with which such interactive reports can be developed is one of the most striking features of the ABAP language.The term "report" is somewhat misleading in the sense that it is also possible to create report programs that modify the data in the underlying database instead of simply reading it.
A customized screen created using Screen Painter,which is one of the tools available in ABAP workbench(T-code = SE51).
Online programs
Online programs (also called module pools) do not produce lists. These programs define more complex patterns of user interaction using a collection of screens. The term “screen” refers to the actual, physical image that the users sees. Each screen also has a “flow logic”; this refers to the ABAP code invoked by the screens, i.e. the logic that initializes screens, responds to a user’s requests and controls the sequence between the screens of a module pool. Each screen has its own Flow Logic, which is divided into a "PBO" (Process Before Output) and "PAI" (Process After Input) section. In SAP documentation the term “dynpro” (dynamic program) refers to the combination of the screen and its Flow Logic.Online programs are not invoked directly by their name, but are associated with a transaction code. Users can then invoke them through customizable, role-dependent, transaction menus.
Apart from reports and online programs, it is also possible to develop sharable code units such as class libraries, function libraries and subroutine pools.
Subroutine pools
Subroutine pools, as the name implies, were created to contain collections of subroutines that can be called externally from other programs. Before release 6.10, this was the only way subroutine pools could be used. But besides subroutines, subroutine pools can also contain local classes and interfaces. As of release 6.10, you can connect transaction codes to methods. Therefore, you can now also call subroutine pools via transaction codes. This is the closest to a Java program you can get in ABAP: a subroutine pool with a class containing a method – say – main connected to a transaction code!
Function pools
Function pools, more commonly known as "function groups", are libraries of functions developed in ABAP. Functions differ from subroutines in that they are self-contained and do not belong to a specific program. ABAP functions accept as input any number of input parameters, return as output any number of output parameters, and raise exceptions if an error condition occurs.
Functions are invoked in ABAP programs by means of the CALL FUNCTION statement. A very important feature of ABAP is the ability to call function modules in another SAP system or in an external application using the RFC (Remote Function Call) mechanism. It is also possible to call functions asynchronously; the ABAP program then does not wait for the function to return but instead continues immediately, while the function executes in a separate context.
Type pools
Type pools are the precursors to general type definitions in the ABAP Dictionary. Before release 4.0, only elementary data types and flat structures could be defined in the ABAP Dictionary. All other types that should’ve been generally available had to be defined with TYPES in type pools. As of release 4.0, type pools were only necessary for constants. As of release 6.40, constants can be declared in the public sections of global classes and type pools can be replaced by global classes.
Class pools
Class pools serve as containers for exactly one global class. Besides the global class, they can contain global types and local classes/interfaces to be used in the global class. A class pool is loaded into memory by using one of its components. For example, a public method can be called from any ABAP program or via a transaction code connected to the method. You maintain class pools in the class builder.
Interface pools
Interface pools serve as containers for exactly one global interface—nothing more and nothing less. You use an interface pool by implementing its interface in classes and by creating reference variables with the type of its interface. You maintain interface pools in the class builder.
ABAP Workbench
The ABAP Workbench contains different tools for editing Repository objects. These tools provide you with a wide range of assistance that covers the entire software development cycle. The most important tools for creating and editing Repository objects are:ABAP Editor for writing and editing program codeABAP Dictionary for processing database table definitions and retrieving global typesMenu Painter for designing the user interface (menu bar, standard toolbar, application toolbar, function key assignment)Screen Painter for designing screens (dynamic programs) for user dialogsFunction Builder for displaying and processing function modules (routines with defined interfaces that are available throughout the system)Class Builder for displaying and processing ABAP Objects classes
The ABAP Dictionary
Enforces data integrity
Manages data definitions without redundancy
Is tightly integrated with the rest of the ABAP/4 Development Workbench.
Enforcing data integrity is the process of ensuring that data entered into the system is logical, complete, and consistent. When data integrity rules are defined in the ABAP/4 Dictionary, the system automatically prevents the entry of invalid data. Defining the data integrity rules at the dictionary level means they only have to be defined once, rather than in each program that accesses that data.The following are examples of data lacking integrity:A date field with a month value of 13An order assigned to a customer number that doesn’t existAn order not assigned to a customerManaging data definitions without redundancy is the process of linking similar information to the same data definition. For example, a customer database is likely to contain a customer’s ID number in several places. The ABAP Dictionary provides the capability of defining the characteristics of a customer ID number in only one place. That central definition then can be used for each instance of a customer ID number.The ABAP Dictionary’s integration with the rest of the development environment enables ABAP programs to automatically recognize the names and characteristics of dictionary objects.Additionally, the system provides easy navigation between development objects and dictionary definitions. For example, as a programmer, you can double-click on the name of a dictionary object in your program code, and the system will take you directly to the definition of that object in the ABAP/4 Dictionary.When a dictionary object is changed, a program that references the changed object will automatically reference the new version the next time the program runs. Because ABAP is interpreted, it is not necessary to recompile programs that reference changed dictionary objects.
ABAP syntax
This brief description of the ABAP syntax begins inevitably with the ubiquitous "Hello World" program.
"Hello World"PROGRAM TEST.
WRITE 'Hello World'.
This example contains two statements, one on each line. The keywords are PROGRAM and WRITE. The program displays a list on the screen. In this case, the list consists of the line "Hello World".
Formatting rules
ABAP has no format restrictions. You can enter statements in any format, so a statement can be indented, you can write several statements on one line, or spread a single statement over several lines. The only requirement is that every statement ends in a period.
You must separate words within a statement with at least one space. The system also interprets the end of line marker as a space.
The two-line "Hello World" program from above could also be written asPROGRAM TEST. WRITE 'Hello World' .
or even as: PROGRAM
TEST.
WRITE
'Hello World'.
Free formatting is convenient, but with complex code, such as deeply nested IF/ELSE blocks, it can get tricky. The ABAP editor therefore offers a "Pretty Printer" function, which can take care of proper indentation.
ABAP statements are not case-sensitive. The following code is perfectly permissible:proGRAm TEsT.
WriTe 'Hello World'.
Users can configure the way source text is presented (all upper case, all lower case, ABAP keywords in upper case and variable names in lower case, etc.) according to their own preference.
One obvious exception to the free-formatting rule are text literals. A text literal is a sequence of alphanumeric characters in the program code enclosed in single quotes. If a text literal in an ABAP statement extends across more than one line, then a ‘&’ character must be used to combine a succession of text literals into a single one. Example:USERPROMPT = 'Please double-click on a line in the output list ' &
'to see the complete details of the transaction.'.
Chained statements
The ABAP programming language allows you to concatenate consecutive statements with an identical first part into a chain statement.
To concatenate a sequence of separate statements, write the identical part only once and place a colon (:) after it. After the colon, write the remaining parts of the individual statements, separating them with commas. Ensure that you place a period (.) after the last part to inform the system where the chain ends.
Chaining is very often used in WRITE statements. WRITE accepts just one argument, so if for instance you wanted to display three fields from a structure called FLIGHTINFO, you would have to code:WRITE FLIGHTINFO-CITYFROM.
WRITE FLIGHTINFO-CITYTO.
WRITE FLIGHTINFO-AIRPTO.
Chaining the statements results in a more readable and more intuitive form:WRITE: FLIGHTINFO-CITYFROM, FLIGHTINFO-CITYTO, FLIGHTINFO-AIRPTO.
In the chain, a colon separates the beginning of the statement from the variable parts. After the colon or commas, you can insert any number of spaces.
You could, for example, write the same statement like this:WRITE: FLIGHTINFO-CITYFROM,
FLIGHTINFO-CITYTO,
FLIGHTINFO-AIRPTO.
In a chain statement, the first part (before the colon) is not limited to the keyword of the statements. For example, the codeSUM = SUM + 1.
SUM = SUM + 2.
SUM = SUM + 3.
SUM = SUM + 4.
could be written in chained form:SUM = SUM + : 1, 2, 3, 4.
Comments
Comments are texts that you can write between the statements of your ABAP program to explain their purpose to a reader. ABAP has two ways to write a comment: by placing an asterisk "*" in the leftmost comumn the entire line becomes a comment (the ABAP editor will show these lines in a different color). Inside a line of code, anything to the right of a double quotation mark is also treated as a comment:***************************************
** Program: BOOKINGS **
** Author: Joe Byte, 07-Jul-2007 **
***************************************
REPORT BOOKINGS.
* Read flight bookings from the database
SELECT * FROM FLIGHTINFO
WHERE CLASS = 'Y' "Y = economy
OR CLASS = 'C'. "C = business
(...)
DATA and TYPES
It is a special strength of ABAP that you can define a great variety of data types and objects that span the spectrum from very elementary data types to very complex and dynamic types. Consequently, the subject of ABAP declarations is quite extensive.
ABAP accepts all data types defined in the SAP dictionary or in Type Pools. Types can also be defined inside the program itself. Object variables take the type of their class. Like many other programming languages, ABAP has a set of "primitive" types. These can be binary numeric (I for integer, F for floating point), packed decimal (P), character (C or N, where the N type is used for numeric strings that can be used in computation) or hexadecimal (X). Date fields (type D) and time fields (type T) have a "dual" nature; in an input/output context they behave like strings, but in a computational context they are numeric integers. This makes date and time calculations extremely easy. For example:DATESENT = '20070901'.
VALIDTO = DATESENT + 60.
WRITE: 'Offer is valid until', VALIDTO DD/MM/YYYY.
In this example, a string literal representing September 1, 2007is assigned to DATESENT. DATESENT is then used in a numeric calculation to produce another data field, VALIDTO. VALIDTO is then output as a string. The optional "DD/MM/YYYY" modifier displays the date in a predefined nformat, here "31/10/2007". Without the modifier the date would display as "20071031".
Data and Types
All ABAP variables must be declared before they are used. The declaration consists of the name, type, length (where applicable), additional modifiers (e.g. the number of implied decimals for a packed decimal field) and optionally an initial value:* Primitive types:
DATA: COUNTER TYPE I,
VALIDITY TYPE I VALUE 60,
TAXRATE(3) TYPE P DECIMALS 1,
LASTNAME(20) TYPE C.* Dictionary types:
DATA: ORIGIN TYPE COUNTRY.* Internal table:
DATA: T_FLIGHTS TYPE TABLE OF FLIGHTINFO,
T_LOOKUP TYPE HASHED TABLE OF FLT_LOOKUP.* Objects:
DATA: BOOKING TYPE REF TO CL_FLT_BOOKING.
Notice the use of the colon to chain together consecutive DATA statements.
ABAP OBJECTS
Object orientation in ABAP is an extension of the ABAP language that makes available the advantages of object-oriented programming, such as encapsulation, interfaces, and inheritance. This helps to simplify applications and make them more controllable.
ABAP Objects is fully compatible with the existing language, so you can use existing statements and modularization units in programs that use ABAP Objects, and can also use ABAP Objects in existing ABAP programs.
ABAP Statements – an Overview
The first element of an ABAP statement is the ABAP keyword. This determines the category of the statement. The different statement categories are as follows:
Declarative Statements
These statements define data types or declare data objects which are used by the other statements in a program or routine. The collected declarative statements in a program or routine make up its declaration part.
Examples of declarative keywords:
TYPES, DATA, TABLES
Modularization Statements
These statements define the processing blocks in an ABAP program.
The modularization keywords can be further divided into:
· Event Keywords
You use statements containing these keywords to define event blocks. There are no special statements to conclude processing blocks - they end when the next processing block is introduced.
Examples of event keywords are:
AT SELECTION SCREEN, START-OF-SELECTION, AT USER-COMMAND
· Defining keywords
You use statements containing these keywords to define subroutines, function modules, dialog modules and methods. You conclude these processing blocks using the END- statements.
Examples of definitive keywords:
FORM ..... ENDFORM, FUNCTION ... ENDFUNCTION, MODULE ... ENDMODULE.
Control Statements
You use these statements to control the flow of an ABAP program within a processing block according to certain conditions.
Examples of control keywords:
IF, WHILE, CASE
Call Statements
You use these statements to call processing blocks that you have already defined using modularization statements. The blocks you call can either be in the same ABAP program or in a different program.
Examples of call keywords:
CALL METHOD, CALL TRANSACTION, SUBMIT, LEAVE TO
Operational Statements
These keywords process the data that you have defined using declarative statements.
Examples of operational keywords:
MOVE, ADD
Unique Concept of Internal Table in ABAP
Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data objects, they save the programmer the task of dynamic memory management in his or her programs. You should use internal tables whenever you want to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for storing and formatting data from a database table within a program. They are also a good way of including very complicated data structures in an ABAP program.
Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects A data type is the abstract description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The data type is also an attribute of an existing data object.
Internal Tables as Data Types
Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type, key, and table type.
Line type
The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the structure is a column in the internal table. However, the line type may also be elementary or another internal table.
Line Type can also refer to an ABAP Object's reference pointer value. If two ABAP Objects are not related, they do not have the same line type. The line type is stored in the value of the reference pointer and can be viewed in the debugger. If one object attempts to access another unrelated object's components, you will receive an error specifying that the line types do not match.
Key
The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify whether the key should be UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries. The uniqueness depends on the table access method.
If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves internal tables. If a table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type is an internal table, the default key is empty.
The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. Internal tables with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember this, for example, if you intend to sort the table according to the key.
Table type
The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table. The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled very quickly, since the system does not have to check whether there are already existing entries.
Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.
Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique. When you define the table, you must specify the key as UNIQUE.
Generic Internal Tables
Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic internal tables to specify the types of field symbols and the interface parameters of procedures. You cannot use them to declare data objects.
Internal Tables as Dynamic Data Objects
Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects, since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration) is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the internal table.
Choosing a Table Type
The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most frequently executed.
Standard tables
This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key access, the response time is logarithmically proportional to the number of table entries.
Sorted tables
This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the table key in the WHERE condition.
Hashed tables
This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data.
Advanced Topics
Batch Input: Concepts
Processing Sessions
The above figure shows how a batch input session works.
A batch input session is a set of one or more calls to transactions along with the data to be processed by the transactions. The system normally executes the transactions in a session non-interactively, allowing rapid entry of bulk data into an R/3 System.
A session records transactions and data in a special format that can be interpreted by the R/3 System. When the System reads a session, it uses the data in the session to simulate on-line entry of transactions and data. The System can call transactions and enter data using most of the facilities that are available to interactive users.
For example, the data that a session enters into transaction screens is subject to the same consistency checking as in normal interactive operation. Further, batch input sessions are subject to the user-based authorization checking that is performed by the system.
Advantages of ABAP over Contemporary languages
ABAP Objects offers a number of advantages, even if you want to continue using procedural programming. If you want to use new ABAP features, you have to use object-oriented interfaces anyway.
Sharing Data: With ABAP shared objects, you can aggregate data once at a central location and the different users and programs can then access this data without the need for copying.
Exception Handling: With the class-based exception concept of ABAP, you can define a special control flow for a specific error situation and provide the user with information about the error.
Developing Persistency: For permanent storage of data in ABAP, you use relational database tables by means of database-independent Open SQL, which is integrated in ABAP. However, you can also store selected objects transparently or access the integrated database or other databases using proprietary SQL.
Connectivity and Interoperability: The Exchange Infrastructure and Web services are the means by which developers can implement a service-oriented architecture. With Web services, you can provide and consume services independently of implementation or protocol. Furthermore, you can do so within NetWeaver and in the communication with other systems. With the features of the Exchange Infrastructure, you can enable, manage, and adapt integration scenarios between systems.
Making Enhancements: With the Enhancement Framework, you can enhance programs, function modules, and global classes without modification as well as replace existing code. The Switch Framework enables you activate only specific development objects or enhancements in a system.
Considerable Aspects
It follows a list of aspects to be considered during development. The list of course is not complete.
Dynpro persistence
When implementing dynpros one has to care for himself to read out and persist the necessary fields. Recently it happened to me that I forgot to include a field into the UPDATE-clause which is an error not so easy to uncover if you have other problems to be solved in the same package. Here, tool-support or built-in mechanisms would help.
The developer could help himself out by creating something like a document containing a cookbook or guide in which parts of a dynpro logic one has to care about persistence. With that at hand, it would be quite easy finding those bugs in short time. Maybe a report scanning for the definition of the dynpro fields to be persisted could scan the code automatically, too.
Memory Cache
It should be common-sense that avoiding select-statements onto the database helps reducing the server load. For that the programmer either can resort to function modules if available. This maybe is the case for important tables. Or the programmer needs to implement his own logic using internal tables. Here, the standard software package could provide the developer with a tool or a mechanism auto-generating memory cached tables resp. function modules implementing this.
Sometimes buffering of database tables could be used, if applicable. But that would require an effort in customizing the system and could drain down system performance overall, especially if a table is involved that has a central role.
Interfaces
It should be noticed that some function modules available have an incomplete interface. That means, the interface does not include all parameters evaluated by the logic of the function module. For example, global variables from within the function group could be read out, which cannot be influenced by the general caller. Or memory parameters are used internally to feed the logic with further information.
One workaround here would be copying the relevant parts of the logic to a newly created function module and then adapt it to the own context. This sometimes is possible, maybe if the copied code is not too lengthy and only a few or no calls to other logic is part of it.
A modification of the SAP code could be considered, if the modification itself is unavoidable (or another solution would be not justifiable by estimated effort to spend on it) and if the location of the modification seems quite safe against future upgrades or hot fixes. The latter is something that could be evaluated by contacting the SAP hotline or working with OSS message (searching thru existing one, perhaps open a new one).
Example
'From SAP NetWeaver:'*-----------
* set an exclusive lock at level object-type & object-id
*------------------------------------------
IF NOT lf_bapi_error = true.
IF ( NOT istourhd-doc_type IS INITIAL ) AND
( NOT istourhd-doc_id IS INITIAL )
CALL FUNCTION 'ENQUEUE_/DSD/E_HH_RAREF'
EXPORTING
obj_typ = istourhd-doc_type
obj_id = istourhd-doc_id
EXCEPTIONS
foreign_lock = 1
system_failure = 2
OTHERS = 3.
IF sy-subrc <> 0.
* terminate processing...
lf_bapi_error = true.—
* ...and add message to return table
PERFORM set_msg_to_bapiret2
USING sy-msgid gc_abort sy-msgno
sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4
gc_istourhd gc_enqueue_refdoc space
CHANGING lt_return.
ENDIF.
ENDIF.
ENDIF. "
Example Report(Type - ALV(ABAP List Viewer))REPORT Z_ALV_SIMPLE_EXAMPLE_WITH_ITAB .
************************************************************************
*Simple example to use ALV and to define the ALV data in an internal
*table
************************************************************************
*data definition
tables:
marav. "Table MARA and table MAKT
*---------------------------------------------------------------------*
* Data to be displayed in ALV
* Using the following syntax, REUSE_ALV_FIELDCATALOG_MERGE can auto-
* matically determine the fieldstructure from this source program
Data:
begin of imat occurs 100,
matnr like marav-matnr, "Material number
maktx like marav-maktx, "Material short text
matkl like marav-matkl, "Material group (so you can test to make
" intermediate sums)
ntgew like marav-ntgew, "Net weight, numeric field (so you can test to
"make sums)
gewei like marav-gewei, "weight unit (just to be complete)
end of imat.
*---------------------------------------------------------------------*
* Other data needed
* field to store report name
data i_repid like sy-repid.
* field to check table length
data i_lines like sy-tabix.
*---------------------------------------------------------------------*
* Data for ALV display
TYPE-POOLS: SLIS.
data int_fcat type SLIS_T_FIELDCAT_ALV.
*---------------------------------------------------------------------*
select-options:
s_matnr for marav-matnr matchcode object MAT1.
*---------------------------------------------------------------------*
start-of-selection.
* read data into table imat
select * from marav
into corresponding fields of table imat
where
matnr in s_matnr.
* Check if material was found
clear i_lines.
describe table imat lines i_lines.
if i_lines lt 1.
* Using hardcoded write here for easy upload
write: /
'No materials found.'.
exit.
endif.
end-of-selection.
* To use ALV, we need a DDIC-structure or a thing called Fieldcatalogue.
* The fieldcatalouge can be generated by FUNCTION
* 'REUSE_ALV_FIELDCATALOG_MERGE' from an internal table from any
* report source, including this report.
*---------------------------------------------------------------------*
* Store report name
i_repid = sy-repid.
* Create Fieldcatalogue from internal table
CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE'
EXPORTING
I_PROGRAM_NAME = i_repid
I_INTERNAL_TABNAME = 'IMAT' "capital letters!
I_INCLNAME = i_repid
CHANGING
CT_FIELDCAT = int_fcat
EXCEPTIONS
INCONSISTENT_INTERFACE = 1
PROGRAM_ERROR = 2
OTHERS = 3.
*explanations:
* I_PROGRAM_NAME is the program which calls this function
*
* I_INTERNAL_TABNAME is the name of the internal table which you want
* to display in ALV
*
* I_INCLNAME is the ABAP-source where the internal table is defined
* (DATA....)
* CT_FIELDCAT contains the Fieldcatalouge that we need later for
* ALV display
IF SY-SUBRC <> 0.
write: /
'Returncode',
sy-subrc,
'from FUNCTION REUSE_ALV_FIELDCATALOG_MERGE'.
ENDIF.
*This was the fieldcatlogue
*---------------------------------------------------------------------*
*
* Call for ALV list display
CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY'
EXPORTING
I_CALLBACK_PROGRAM = i_repid
IT_FIELDCAT = int_fcat
TABLES
T_OUTTAB = imat
EXCEPTIONS
PROGRAM_ERROR = 1
OTHERS = 2.
*explanations:
* I_CALLBACK_PROGRAM is the program which calls this function
*
* IT_FIELDCAT (just made by REUSE_ALV_FIELDCATALOG_MERGE) contains
* now the data definition needed for display
*
* I_SAVE allows the user to save his own layouts
*
* T_OUTTAB contains the data to be displayed in ALV
IF SY-SUBRC <> 0.
write: /
'Returncode',
sy-subrc,
'from FUNCTION REUSE_ALV_LIST_DISPLAY'.
ENDIF.
credit by : http://en.wikipedia.org/wiki/ABAP
SAP MM Tables
Materials Management Tables
EINA Purchasing Info Record- General Data
EINE Purchasing Info Record- Purchasing Organization Data
MAKT Material Descriptions
MARA General Material Data
MARC Plant Data for Material
MARD Storage Location Data for Material
MAST Material to BOM Link
MBEW Material Valuation
MKPF Header- Material Document
MSEG Document Segment- Material
MVER Material Consumption
MVKE Sales Data for materials
RKPF Document Header- Reservation
T023 Mat. groups
T024 Purchasing Groups
T156 Movement Type
T157H Help Texts for Movement Types
MOFF Lists what views have not been created
Purchasing Tables
A501 Plant/Material
EBAN Purchase Requisition
EBKN Purchase Requisition Account Assignment
EKAB Release Documentation
EKBE History per Purchasing Document
EKET Scheduling Agreement Schedule Lines
EKKN Account Assignment in Purchasing Document
EKKO Purchasing Document Header
EKPO Purchasing Document Item
IKPF Header- Physical Inventory Document
ISEG Physical Inventory Document Items
LFA1 Vendor Master (General section)
LFB1 Vendor Master (Company Code)
NRIV Number range intervals
RESB Reservation/dependent requirements
T161T Texts for Purchasing Document Types
EINA Purchasing Info Record- General Data
EINE Purchasing Info Record- Purchasing Organization Data
MAKT Material Descriptions
MARA General Material Data
MARC Plant Data for Material
MARD Storage Location Data for Material
MAST Material to BOM Link
MBEW Material Valuation
MKPF Header- Material Document
MSEG Document Segment- Material
MVER Material Consumption
MVKE Sales Data for materials
RKPF Document Header- Reservation
T023 Mat. groups
T024 Purchasing Groups
T156 Movement Type
T157H Help Texts for Movement Types
MOFF Lists what views have not been created
Purchasing Tables
A501 Plant/Material
EBAN Purchase Requisition
EBKN Purchase Requisition Account Assignment
EKAB Release Documentation
EKBE History per Purchasing Document
EKET Scheduling Agreement Schedule Lines
EKKN Account Assignment in Purchasing Document
EKKO Purchasing Document Header
EKPO Purchasing Document Item
IKPF Header- Physical Inventory Document
ISEG Physical Inventory Document Items
LFA1 Vendor Master (General section)
LFB1 Vendor Master (Company Code)
NRIV Number range intervals
RESB Reservation/dependent requirements
T161T Texts for Purchasing Document Types
SAP SD Tables
KONV Conditions for Transaction Data
KONP Conditions for Items
LIKP Delivery Header Data
LIPS Delivery: Item data
VBAK Sales Document: Header Data
VBAP Sales Document: Item Data
VBBE Sales Requirements: Individual Records
VBEH Schedule line history
VBEP Sales Document: Schedule Line Data
VBFA Sales Document Flow
VBLB Sales document: Release order data
VBLK SD Document: Delivery Note Header
VBPA Sales Document: Partner
VBRK Billing: Header Data
VBRP Billing: Item Data
VBUK Sales Document: Header Status and Administrative Data
VBUP Sales Document: Item Status
VEKP Handling Unit - Header Table
VEPO Packing: Handling Unit Item (Contents)
VEPVG Delivery Due Index
KONP Conditions for Items
LIKP Delivery Header Data
LIPS Delivery: Item data
VBAK Sales Document: Header Data
VBAP Sales Document: Item Data
VBBE Sales Requirements: Individual Records
VBEH Schedule line history
VBEP Sales Document: Schedule Line Data
VBFA Sales Document Flow
VBLB Sales document: Release order data
VBLK SD Document: Delivery Note Header
VBPA Sales Document: Partner
VBRK Billing: Header Data
VBRP Billing: Item Data
VBUK Sales Document: Header Status and Administrative Data
VBUP Sales Document: Item Status
VEKP Handling Unit - Header Table
VEPO Packing: Handling Unit Item (Contents)
VEPVG Delivery Due Index
What is SAP MM
SAP MM (Materials Management) is a module of the SAPEnterprise Resource Planning (ERP) package that is used for Procurement Handling and Inventory Management.
The module has two important master data - material and vendor. Broadly, the various levels that can be defined for a SAP MM implementation are: Client, Company Code, Plant, Storage Location and Purchase Organization
The module has two important master data - material and vendor. Broadly, the various levels that can be defined for a SAP MM implementation are: Client, Company Code, Plant, Storage Location and Purchase Organization
credit by : http://en.wikipedia.org
สมัครสมาชิก:
บทความ (Atom)