BADI

A business add-in has two important attributes that you must define:
Reusable
Filter-dependent
If you want the business add-in to support multiple parallel implementations, select Reusable. The sequence in which the implementations will be processed is not defined. Even if the business add-in does not support multiple use, you can still have more than one implementation for it. However, only one implementation can be active at a time.

If you make a business add-in filter-dependent, you can make calls to it depending on certain conditions. You must specify the filter type in the form of a data element. The value table of the domain used by the data element contains the valid values for the implementation.

When the enhancement method is called, a filter value must be passed to the interface.

You can include function codes in a Business Add-In definition (similarly to menu exits in customer exits). To do this, enter the program name and function code, and a short description in the relevant fields.

Restrictions:

It is not currently possible to create BAdIs that consits only of menu enhancements (function codes).

If you use menu enhancements, you cannot reuse a BAdI or make it filter-dependent.


The system proposes a name for the interface and the generated class. You can, in principle, change the name of the interface to anything you like. However, your BAdI will be easier to understand if you retain the proposed name.

The name of the generated class is composed as follows:
Namespace prefix
CL_ (to signify a class in general)
EX_ (stands for "exit")
Name of Business Add-In

If you double-click on the interface name, the system switches to the Class Builder, where you can define the interface methods.
A BAdI interface can have several interface methods.

You can use all of the normal functions of the Class Builder. For example, you can:
Define interface methods
Define interface parameters for the methods
Declare the attributes of the interface
If the business add-in is filter-dependent, you must define an import parameter flt_val for each method. Otherwise, you define the interface parameters you need for the enhancement.

Once you have finished working on your interface, you must activate it. This generates the adapter class for the Business Add-In.

If you change the interface, the adapter class is automatically regenerated.
You can also generate the adapter class explicitly at any time by choosing Utilities -> Regenerate from the initial screen of the Business Add-In maintenance transaction.


To call a business add-in method in an application program, you must include three statements in the program:
Declare a reference variable (1) with reference to the business add-in interface (in our example, "exit_ref").
Call the static method GET_INSTANCE of the service class CL_EXITHANDLER (2). This returns an instance of the required object. This involves an implicit narrow cast, so that only the interface methods of the object with the reference variable "exit_ref" can be addressed.
You can now call all of the methods of the business add-in. Make sure you specify the method interfaces correctly.

If your Business Add-In is filter-specific, you must pass an appropriate value to the parameter flt_val.

Business add-ins are a natural extension of the conventional enhancement technique. They have taken over the administration layer from customer exits, along with the availability of the various enhancement components.
They adopted the idea of reusability from Business Transaction Events, and have been implemented using a consistent object-oriented approach.
The object-oriented implementation provides previously unavailable opportunities. For example, it would be possible to enhance the object "Document". It would be possible to provide a new instance of the enhancement for each individual document.

The components in parentheses in the graphic have not yet been implemented:
Screen enhancements
Table enhancements

These enhancement components are planned for later releases. There will then also be a migration tool for converting previous enhancements into the new form.

WHAT IS THE DIFFERENCE BETWEEN BADI'S AND USER EXITS IN SAP?

Business Add-Ins are a new SAP enhancement technique based on ABAP Objects. They can be inserted into the SAP System to accommodate user requirements too specific to be included in the standard delivery. Since specific industries often require special functions, SAP allows you to predefine these points in your software.

As with customer exits two different views are available:

In the definition view, an application programmer predefines exit points in a source that allow specific industry sectors, partners, and customers to attach additional software to standard SAP source code without having to modify the original object.

In the implementation view, the users of Business Add-Ins can customize the logic they need or use a standard logic if one is available.

In contrast to customer exits, Business Add-Ins no longer assume a two-level infrastructure (SAP and customer solutions), but instead allow for a multi-level system landscape (SAP, partner, and customer solutions, as well as country versions, industry solutions, and the like). Definitions and implementations of Business Add-Ins can be created at each level within such a system infrastructure.

SAP guarantees the upward compatibility of all Business Add-In interfaces. Release upgrades do not affect enhancement calls from within the standard software nor do they affect the validity of call interfaces. You do not have to register Business Add-Ins in SSCR.

The Business Add-In enhancement technique differentiates between enhancements that can only be implemented once and enhancements that can be used actively by any number of customers at the same time. In addition, Business Add-Ins can be defined according to filter values. This allows you to control add-in implementation and make it dependent on specific criteria (on a specific Country value, for example).

All ABAP sources, screens, GUIs, and table interfaces created using this enhancement technique are defined in a manner that allows customers to include their own enhancements in the standard. A single Business Add-In contains all of the interfaces necessary to implement a specific task.

The actual program code is enhanced using ABAP Objects. In order to better understand the programming techniques behind the Business Add-In enhancement concept, SAP recommends reading the section on ABAP Objects.

SAP R/3 ABAP/4 FAQ – User Exits

1. What is the gap bridging / Enhancement / Gap Development?

Customer changes to SAP repository objects without modifications.

2. Why do you need to use exits?

They do not affect standard SAP source code, do not affect software upgrade.

3. Various types of enhancement

Program, Menu, Screen, Field

4. How do you identify the user exits?

Use the transaction CMOD and for that respective development class exits available with + sign.

5. What do mean by SSCR & OSS.

“SAP Software Change Registration” & “Online Service System”.

6. How does the production system take the benefit from the user exit?

Development would be carried out in the Development system and the changes / user exits can be transported to the target system (quality or production)

Performance and scalability in SAP?

The performance of ALE business processes depends on many factors (type of business process, number of messages, activities running on the distributed systems, hardware, and so on).

To obtain detailed information about the performance a sizing procedure is required.

The sizing procedure for SAP systems linked via ALE can be divided into two independent steps. In the first step only the activities within one system must be taken into account, in the second step the additional load created by the communication between the systems has to be determined.

The total processing capacity (CPU, main memory, disk space and network bandwidth) needed for each individual SAP system can be calculated as the sum of the two steps of the sizing procedure.

The reason for choosing this simplified sizing model is the following. The resource consumption of a business transaction depends only little on the fact whether the transaction was executed by an online user, a batch job or an interface program processing an IDoc.

This is essentially because the same activities like consistency checks or business functions have to be performed in any case.

Of course the error handling for online users is different from the error handling in batch processing. On the other hand, for batch jobs or interface programs additional protocols have to be written to ensure restartability.

The first step of the sizing procedure is therefore either a user or a throughput based sizing for each SAP system. Thus the same input data is required and the same procedures and models have to be applied as in the standard sizing methodology for a single SAP system.

For the second sizing step - calculating the impact of the data transfer between the ALE linked systems - it is essential to know how many messages of a certain type will be exchanged between the different systems per time interval.

In the receiving system these messages will create additional objects or changes to existing objects, this can be taken into account by a throughput based sizing and has to be added to the numbers calculated for this SAP system in the first sizing step.

The overhead created in the sending system is in most cases less than 10% and can therefore be neglected.

This is due to the fact that normally messages are not sent immediately but bundled to reduce the communication overhead.

Measurements and experience show that the additional network bandwidth needed by ALE in a LAN scenario is much smaller than the network traffic between application and database server because of data compression; for WAN scenarios, however, the size and amount of the IDocs transferred has to be taken into account.

The same sizing considerations are valid for SAP systems connected to non-SAP systems, too.

What is the relationship between ALE and middleware in SAP?

For distributed business processes many different services are required. Most of these services are offered by SAP. For some of these services you can also use products that are provided by SAP's complementary software partners or by other companies:

The communication service for doing the pure communication is usually done via Remote Function Call (RFC).

RFC is provided by SAP for most platforms both for synchronous and asynchronous communication. There are other messaging systems for the communication service available as well, like IBM's MQSeries.

However, the communication between SAP and the messaging system is still done via RFC.

For the serialization of asynchronous communication the RFC provides little functionality at the moment.

The serialization has to be checked by the application. ALE offers some support to do these checks.

The serialization of the RFC communication will be improved in the future. Serialization services are provided by some of the existing messaging systems, but even they can not guaranty a 100% serialization of the communication, since they use RFC for the connection to SAP.

The monitoring and error handling of the communication is done via services provided by the RFC and ALE. If messaging systems are used for the communication they also offer some monitoring and error handling functionality.

If a non-SAP system is involved in the ALE business scenario and this system does not understand SAP's BAPI or IDoc interfaces, the data has to be mapped to any interface structure that this system offers.

For this mapping SAP does not provide a service but it certifies mapping tools from software partners. These tools are called ALE translator. The most known product in this area is probably Mercator from TSI International Software. The same kind of mapping can also be done by 'EDI converters'.

Another type of middleware products offer process ware. This is mainly a combination of the communication service, the mapping service and a set of rules for the mapping. Some ALE translator can be used for this as well.

Receiver determination is one of the ALE services (see above). Parts of this service can also be provided by some of the messaging systems, but you cannot use these systems without using ALE receiver determination.

For the other ALE services like application monitoring, application error handling, semantic synchronization and business process harmonization, there are no middleware products available as a replacement of ALE.

ALE is open for the use of middleware products for the distribution, but in most cases the additional middleware is not necessary.

In a communication between different SAP systems usually the use of additional middleware makes no sense at all.

For the communication between SAP and non-SAP systems there might be some benefits, especially if the middleware is used at the company already. The only middleware tool that is really required if the non-SAP system does not understand BAPIs or IDocs is an ALE translator.

. Why does SAP uses ALE instead of database replication or distributed databases in SAP?

Database replication is another possibility for doing business object synchronization.

However, there are some major disadvantages with database replication. At the moment database replication is database dependent and release dependent within one database.

This makes database replication impossible for the use with non-SAP systems and even for the replication between SAP Systems you have to make sure that all systems are running on the same SAP release and the same database release of a single database vendor.

Furthermore, with database replication you cannot do things like field conversions or version changes. ALE does not have these shortcomings because it offers application driven data replication independent of the underlying database.

Another technology, distributed databases, is no alternative for ALE at the moment, either. There are some good results of distributed databases available, but the performance is far from sufficient for using it with larger applications like SAP.

Which kind of interfaces do ALE business processes use in SAP?

ALE business processes are integrated processes across distributed systems, requiring interfaces between the systems.

These interfaces have to be stable to enable the communication between different releases and to reduce the impact of release changes within the distributed environment.

In SAP R/3 release 3.0 and 3.1 ALE uses IDocs as interfaces. An IDocs is a data container for transferring messages asynchronously.

They are release independent. Since SAP Release 3.1G BAPIs are a new type of object oriented, stable interfaces that can be called synchronously or asynchronously.

Asynchronous BAPIs use IDocs as data containers. ALE business processes can use BAPIs as well. In the future new ALE business processes will use BAPIs as interfaces. But the existing IDocs will still be supported.

In time, BAPIs will be created with similar functionality to existing IDoc interfaces.

Synchronous vs. asynchronous links in SAP?

When distributed applications are linked by ALE business processes, the question often arises as to how tight the link should be. Synchronous and asynchronous links have both advantages and disadvantages.

Synchronous links have the advantage that the sub-process on the server can return values to the sub-process on the client that has started the link.

Problems with synchronous links occur if the communication line or the server is temporarily not available. If this happens, the sub-process on the client can not be finished (otherwise there would be data inconsistencies).

(Example: There is a logistics system and a financial system. Every stock movement in logistics has to be posted in the general ledger of the financial system. If the link between logistics and finance is synchronous, no stock movement can be recorded in the logistics system if the communication line to the financial system is down.)

Because of this, synchronous links are usually used if the client only wants to get some data from the server and the sub-processes on the server do not have to write any data to the database.

With asynchronous links the sub-process on the client can be finished even if the communication line or the server is not available.

In this case the message is stored in the database and the communication can be done later. The disadvantage of asynchronous links is that the sub-process on the server can not return information to the calling sub-process on the client.

A special way for sending information back to the client is required. In addition, a special error handling mechanism is required to handle errors on the receiving side.

Asynchronous links are used if a synchronous link is not applicable. For the problems with sending return information to the client and with error handling there is some support from the ALE services.

Which ALE services are available and what do they do?

To integrate distributed systems you need more than a communication infrastructure and interfaces. Some additional services are required that are provided by ALE:

Business process harmonization:

Within system overlapping business processes multiple functions running on multiple systems are involved and connected through multiple interfaces. The processes are combinations of functions (sub-processes) running on the single systems.

(Example: A business process for customer order management involves functions in sales, manufacturing, warehouse management, finance, and so on. It is possible that the sales functions are carried out on another system than the manufacturing, the warehouse management or the accounting. Furthermore, some information exchange with the customer, a supplier or a bank may be involved in the process.)

ALE helps to coordinate the whole business process by defining it within a global model. In this model the business rules for the distribution are defined.

Via the model the sub-processes get to know which part of the overall process they have to do themselves and when they have to pass the process over to another system. Through this the whole business process gets harmonized.

Receiver determination:

For distributed business processes a sub-process on one application (client) has to start another sub-process on another application (server). It is important that the new sub-process is started on the right server.

Which server is the right one can not be defined by technical values, it depends on the business content of the process.

(Example: A sales system forwards customer orders to two different production systems. To which system a special sales order is forwarded depends on the entries in the sales order (this may depend, for instance, on the ordered material or on the customer). One sales order may also be split into two or more different orders that may be forwarded to different production systems.)

To notify the client which system is the receiver of the communication (server), ALE uses a distribution model.

From this model the applications get the information about the right server. There are special ALE BAPIs and function modules available for this. The receiver determination makes sure that the information is sent to the right places.

Business object synchronization (semantic synchronization):

If business processes run across distributed systems, they have to share some data to be harmonized.

This is data like business information data, master data or customizing data. If this data is changed in any of the distributed systems, other systems have to be informed about the change. There has to be some kind of subscription of the data.

ALE provides a special service for this data synchronization. This service can detect data changes and distribute the information to those systems that need to know about the change. This service also defines which data is shared.

You can determine which fields of a data object shall be common and which fields may vary locally.

Consistency checks:

For a business process running across two distributed applications there has to be some harmonization of the sub-processes in the single applications.

For making sure that the sub processes are harmonized there are special ALE consistency check tools. These tools help to find and repair inconsistencies. By this it can be ensured that the whole ALE business process works in the right way.

Monitoring:

For the monitoring of distributed processes it is not enough to monitor all activities on the single systems.

The overall business process has to be monitored. The ALE monitoring services provide detailed information about the communication process, the sub-process on the other systems and its results.

Database links are created between the business objects in question on the client and the server. This is especially important for loosely coupled applications with asynchronous links. In this case the server can not give return values back to the client directly so that the ALE monitoring is the only channel for feedback.

Error handling:

Another problem with asynchronous communication is error handling. If an error occurs on the server the calling process on the client may have finished already. So the server can not return the error message to the client.

A special error handling process required. This process is one of the ALE services. It uses workflow functionality to identify the error and to start the required error handling.

Which ALE business processes are available in SAP?

ALE business processes are integrated business processes that run across distributed systems. This can be two different SAP systems, links between SAP and non-SAP systems, SAP and Web-servers (Internet Application Components) or SAP and desktop applications. The links between the systems may be loosely (asynchronous) or tightly (synchronous) coupled.

These business processes are release independent and can run between different release levels of the systems.

Many SAP applications offer ALE distribution processes. The following list gives some examples:

• Master data replication:
  - Material
  - Customer
  - Vendor
  - General Ledger accounts
  - Bill of materials
  - ...
• Accounting:
  - Links to logistic systems
  - Distributed financial accounting
  - Distributed cost center accounting
  - Distributed special ledger
  - Profitability analysis
  - Distributed profit center accounting
  - Consolidation
  - Treasury
  - ...
• Logistics:
  - Reallocation of materials
  - Distribution of sales and shipping
  - Product data management
  - Purchasing contracts
  - Sales and operations planning
  - Warehouse management
  - Links to warehouse control systems
  - Links to production optimization systems
  - Links to transport planning systems
  - ...
• Information systems:
  - SAP Business Information Warehouse (BW)
  - Exchange of data between information systems
  - Web reporting
  - ...
• Human resources:
  - Human resources as a single component
  - Payroll results
  - Travel expense accounting
  - Links to time collecting systems
  - ...

However, these standard solutions may not fit 100% for a company. There may be differentiation in the business process or a required distributed business process is not supported in the standard.

If this happens, ALE provides tools that can be used to adapt a standard ALE business process or to create a new distributed business process.

What is the relationship between ALE and Middleware In SAP?

Electronic Data Interchange (EDI) is a term for the transfer of business messages between two systems.

There are many such messages, the most common of these include a customer sending a purchase order message to a vendor, or a vendor sending an invoice message to a customer. Classic EDI is mainly restricted on the exchange of transactional data, no master data or configuration data.

In most cases, EDI replaces the transfer of paper copies of these documents. Via the messages ALE business processes can be implemented between business partners. The EDI messages also use the ALE services.

For the communication between different types of systems special EDI messages are defined as standards for inter company communication.

There are many standards for these messages - in the United States, the ANSI X.12 standard is the most prevalent, in Europe, the UN/EDIFACT standard is used.

For sending EDI messages the information has to be converted into an EDI standard. With SAP systems this is done by EDI subsystems.

This conversion is the only difference between EDI messages and other messages used in ALE business processes. The processing of these messages on the SAP System is the same as the processing of other ALE messages.

When should ALE be used?

Besides the benefits of ALE there are also reasons not to distribute:

• The functional scope in a distributed environment is restricted. Not all functionality that is available in an integrated SAP system can be used with distributed systems in the standard yet. Although ALE provides tools to create new ALE business processes or to enhance existing business processes, this does involve additional expenditure.
• Each company needs some organizational standards and data harmonization. In a distributed environment less standards are required than on a single integrated system. However, in a distributed environment the maintenance of the standards and the data harmonization is more difficult than on a single system.
• The administration of decentralized systems is more expensive. Support and service costs for hardware and software in decentralized systems are higher than these costs in a single centralized system.

ALE should be used in a company if the benefits of ALE for this company outweigh the reasons against distribution.

For this you always need to carry out a company specific investigation, in which you also should consider the culture of the company. ALE is good for some companies but not for all.

What are the benefits of ALE In SAP?

With ALE companies get the opportunity to improve business performance and to solve organizational or technical issues.

Through distribution you can decentralize your business, enabling local units to operate independently from each other.

This flexibility enables the local units to return better business results than in a centralized environment. They have the necessary flexibility to optimize business processes in different organizational units and can ensure that information systems can handle the speed of change in rapidly expanding markets.

Distribution allows a high level of freedom, provided that this level of freedom has been clearly defined.

On the other hand, some companies, that already have a distributed organization with different computer systems in the local units, have the opportunity to link their units through ALE business processes.

This enables them for example to provide a 'one face to the customer' approach. Another area that can benefit through ALE are virtual organizations (partnerships between independent companies, joint ventures and mergers and acquisitions).

Of course, in many cases an integrated solution based on a single system is not possible at all. Some applications used by a company can not run on the same computer system. This includes legacy systems or complementary software.

It may also be possible that a company uses different SAP industry solutions or specific country solutions, which do not run on the same SAP System. If these applications run on different systems they can not be linked by a central database but have to use a special integration mechanism like ALE.

In this way ALE also links SAP Core Systems to other SAP components like CRM, Business Information Warehouse or APO.

Besides the benefits of having an improved flexibility in setting up the whole business processes, ALE may also reduce costs, in particular costs of upgrading.

If the whole business is run on one integrated system you have to upgrade the whole system, even if only one part of your company (e.g. human resources) requires an update. So the entire company is affected by the upgrade project and all users have to be trained for the new release.

Within a distributed environment with release independent interfaces, like those provided by ALE, you can focus the upgrade project on that part of the company that has to be upgraded. The other parts of the company are not involved and need no training. This can save a lot of money. Furthermore, existing investments are protected.

Another cost factor for distribution might be communication costs. For an overseas connection it can be more expensive to provide online access to one central system (T1) than to connect distributed systems to each other (64K line).

There might also be some technical reasons for distributed systems. If some parts of the business have special requirements for security of data access (e.g. human resources), this can be set up much safer on a standalone system, which is, however, linked to other parts of the company through distributed business processes.

A similar example is high availability. High availability is usually required by the operations part of the company (production, logistics) but not by other areas (e.g. financials, human resources). In a distributed environment high availability can be set up for specific parts of the environment instead of for the whole business. This can also reduce costs.

In a distributed environment you can not decrease the overall workload of the systems but you can separate the user workloads on different systems.

Through this scalability you can improve performance. Another benefit of distributed systems is that if a technical failure occurs on one system, all other systems continue to operate.

Only a small part of the business is disrupted by the error. On one central system such an error would disrupt the entire business.

What is ALE In SAP?

Application Link Enabling (ALE) is a set of business processes and tools that allow applications on different computer systems to be linked. This can be done between different SAP systems as well as between SAP and non-SAP systems.

In a single SAP system different applications are integrated via a single database (e.g. finance, sales, production, human resources).

However, many companies do not have just one integrated system but a distributed environment with different applications running on different systems. To run the whole business in such an environment the distributed applications have to be linked. This can be done through Application Link Enabling (ALE).

ALE provides distributed business processes that can be used to link the applications on different platforms.

There are some ALE business processes delivered in the standard SAP system. Furthermore, there are tools that can be used to change the existing ALE business processes or to implement new distributed business processes.

Besides the business processes there are special ALE services that are required to set up and control a distributed environment. These services include a distribution model, business object synchronization and tools for monitoring or error handling.

ALE is a major part of SAP's Business Framework Architecture. Besides the basis middleware, that provides the communication between components, and the interfaces (BAPIs), ALE business processes and ALE services enable the cooperation of the single components within the framework. That makes ALE the glue of the Business Framework.

INTERNAL TABLES IN ABAP

There are two ways of accessing the records in an internal table:

By copying individual records into a work area. The work area must be compatible with the line type of the internal table.

You can access the work area in any way, as long as the component you are trying to access is not itself an internal table. If one of the components is an internal table, you must use a further work area, whose line type is compatible with that of the nested table.

When you change the internal table, the contents of the work area are either written back to the table or added as a new record.

By assigning the individual data records to an appropriate field symbol. Once the system has read an entry, you can address its components directly via its address. There is no copying to and from the work area. This method is particularly appropriate for accessing large or complex tables.

If you want to read more than one record, you must use a LOOP... ENDLOOP structure. You can then change or delete the line that has just been read, and the system applies the change to the table body. You can also change or delete lines using a logical condition.

When you use the above statements with sorted tables, you must ensure that the sort sequence is maintained.

Within a loop, the INSERT statement adds the data record before the current record in the table. If you want to insert a set of lines from an internal table into another index table, you should use the INSERT LINES OF variant instead.
When you read single data records, you can use two further additions:

In the COMPARING addition, the system compares the field contents of a data record with those in the work area for equality.

In the TRANSPORTING addition, you can restrict the data transport to selected fields.
Other statements for standard tables

SORT [ASCENDING|DESCENDING]
[BY [ASCENDING|DESCENDING] ..
[ASCENDING|DESCENDING]][AS TEXT] [STABLE].

These statements sort the table by the table key or the specified field sequence. If you do not use an addition, the system sorts ascending. If you use the AS TEXT addition, character fields are sorted in culture-specific sequence. The relative order of the data records with identical sort keys only remain constant if you use the STABLE addition.

APPEND INTO SORTED BY .

This statement appends the work area to the ranked list in descending order. The ranked list may not be longer than the specified INITIAL SIZE, and the work area must satisfy the sort order of the table.

The statements listed here can be used freely with both standard and sorted tables.
When you change a single line, you can specify the fields that you want to change using the TRANSPORTING addition. Within a loop, MODIFY changes the current data record.

If you want to delete a set of lines from an index table, use the variant DELETE FROM... TO.. or WHERE... instead of a loop. You can program almost any logical expression after WHERE.

The only restriction is that the first field in each comparison must be a component of the line structure (see the corresponding Open SQL statements). You can pass component names dynamically.

If you want to delete the entire internal table , use the statement CLEAR .
In the LOOP AT... ENDLOOP structure, the statements within the loop are applied to each data record in turn. The INTO addition copies entries one at a time into the work area.

The system places the index of the current loop pass in the system field sy-tabix. When the loop has finished, sy-tabix has the same value that it had before the loop started.

Inserting and deleting lines within a loop affects the following loop passes.
Access to a hashed table is imple mented using a hash algorithm. Simplified, this means that the data records are distributed randomly but evenly over a particular memory area.. The addresses are stored in a special table called the hashing table .

There is a hash function, which determines the address at which the pointer to a data record with a certain key can be found. The function is not injective, that is, there can be several data records stored at a single address. This is implemented internally as a chained list. Therefore, although the system still has to search sequentially within these areas, it only has to read a few data records (usually no more than three). The graphic illustrates the simplest case, that is, in which there is only one data record stored at each address.

Using a hash technique means that the access time no longer depends on the total number of entries in the table. On the contrary, it is always very fast. Hash tables are therefore particularly useful for large tables with which you use predominantly read access.

Data records are not inserted into the table in a sorted order. As with standard tables, you can sort hashed tables using the SORT statement:

SORT [ASCENDING|DESCENDING]
[BY [ASCENDING|DESCENDING] ..
[ASCENDING|DESCENDING]][AS TEXT].

Sorting the table can be useful if you later want to use a loop to access the table.
You can use the statements listed here with tables of all three types. Apart from a few special cases, you can recognize the statements from the extra keyword TABLE. The technical implementation of the statements varies slightly according to the table type.

As a rule, index access to an internal table is quickest. However, it sometimes makes more sense to access data using key values. A unique key is only possible with sorted and hashed tables. If you use the syntax displayed here, your program coding is independent of the table type (generic type specification, easier maintenance).

With a standard table, inserting an entry has the same effect as appending. With sorted tables with a non-unique key, the entry is inserted before the first (if any) entry with the same key.

To read individual data records using the first variant, all fields of that are key fields of must be filled. and can be identical. If you use the WITH TABLE KEY addition in the second variant, you must also specify the key fully. Otherwise, the system searches according to the sequence of fields that you have specified, using a binary search where possible. You can force the system to use a binary search with a standard table using the BINARY SEARCH addition.

In this case, you must sort the table by the corresponding fields first. The system returns the first entry that meets the selection criteria.

Similarly to when you read entries, when you change and delete entries using the key and a work area, you must specify all of the key fields.

You can prevent fields from being transported into the work area during loop processing by using the TRANSPORTING NO FIELDS addition in the WHERE condition. (You can use this to count the number of a particular kind of entry.)

Other statements for all table types

DELETE ADJACENT DUPLICATES FROM
[COMPARING .. | A L L F I E L }|ALL FIELDS}].
The system deletes all adjacent entries with the same key field contents apart from the first entry. You can prevent the system from only comparing the key field using the COMPARING addition. If you sort the table by the required fields beforehand, you can be sure that only unique entries will remain in the table after the DELETE ADJACENT DUPLICATES statement.

Searches all lines of the table for the string . If the search is successful, the system sets the fields sy-tabix and sy-fdpos.

FREE .
Unlike CLEAR, which only deletes the contents of the table, FREE releases the memory occupied by it as well.

If you want to access your data using the index and do not need your table to be kept in sorted order or to have a unique key, that is, when the sequence of the entries is the most important thing, not sorting by key or having unique entries, you should use standard tables. (If you decide you need to sort the table or access it using the key or a binary search, you can always program these functions by hand.)
This example is written to manage a waiting list.

Typical functions are:

Adding a single entry,

Deleting individual entries according to certain criteria,

Displaying and then deleting the first entry from the list,

Displaying someone's position in the list.

For simplicity, the example does not encapsulate the functions in procedures.
The first thing we do in the example is to declare line and table type, from which we can then declare a work area and our internal table. We also require an elementary field for passing explicit index values.

This example omits the user dialogs and data transport, assuming that you understand the principles involved. We really only want to concentrate on the table access:

Adding new entries

The data record for a waiting customer is only added to the table if it does not already exist in it. If the table had a unique key, you would not have had to have programmed this check yourself.

Deleting single entries according to various criteria

The criterion is the key field. However, other criteria would be possible - for example, deleting data records older than a certain insertion date reg_date.

Displaying and deleting the first entry from the list
Once a customer comes to the top of the waiting list, you can delete his or her entry. If the waiting list is empty, such an action has no effect. Consequently, you do not have to check whether there are entries in the list before attempting the deletion.

Displaying the position of a customer in the waiting list
As above, you do not need to place any data in the work area. We are only interested in the values of sy-subrc and sy-tabix. If the entry is not in the table, sy-tabix is set to zero.

At this stage, let us return to the special case of the restricted ranked list:
DATA {TYPE|LIKE} STANDARD TABLE OF ... INITIAL SIZE . ... APPEND INTO SORTED BY .

When you choose to use a sorted table, it will normally be because you want to define a unique key.

The mere fact that the table is kept in sorted order is not that significant, since you can sort any kind of internal table. However, with sorted tables (unlike hashed tables), new data records are inserted in the correct sort order. If you have a table with few entries but lots of accesses that change the contents, a sorted table may be more efficient than a hashed table in terms of runtime.

The aim of the example here is to modify the contents of a database table. The most efficient way of doing this is to create a local copy of the table in the program, make the changes to the copy, and then write all of its data back to the database table. When you are dealing with large amounts of data, this method both saves runtime and reduces the load on the database server. Since the internal table represents a database table in this case, you should ensure that its records have unique keys.

This is assured by the key definition. Automatic sorting can also bring further advantages.

When you change a group of data records, only the fields price and currency are copied from the work area.

This means that, with larger tables, the access time is reduced significantly in comparison with a binary search. In a loop, however, the hashed table has to search the entire table (full table scan). Since the table entries are stored unsorted, it would be better to use a sorted table if you needed to run a loop through a left-justified portion of the key.

It can also be worth using a hashed table but sorting it. A typical use for hashed tables is to buffer detailed information that you need repeatedly and can identify using a unique key. You should bear in mind that you can also set up table buffering for a table in the ABAP Dictionary to cover exactly the same case. However, whether the tables are buffered on the application table depends on the size of the database table.

Buffering in the program using hashed tables also allows you to restrict the dataset according to your own needs, or to buffer additional data as required.
In this example, we want to allow the user to enter the name of a city, and the system to display its geographical coordinates.


First, we fill our "buffer table" city_list with values from the database table sgeocity. Then, we read an entry from the hashed table, specifying the full key.
The details are displayed as a simple list. At this point, it is worth repeating that you should only use this buffering technique if you want to keep large amounts of data locally in the program. You must ensure that you design your hashed table so that it is possible to specify the full key when you access it from your program.

You can define internal tables either with (WITH HEADER LINE addition) or without header lines. An internal table with header line consists of a work area (header line) and the actual table body. You address both objects using the same name. The way in which the system interprets the name depends on the context. For example, the MOVE statement applies to the header line, but the SEARCH statement applies to the body of the table.


To avoid confusion, you are recommended to use internal tables without header lines. This is particularly important when you use nested tables. However, internal tables with header line do offer a shorter syntax in several statements (APPEND, INSERT, MODIFY, COLLECT, DELETE, READ, LOOP).

Within ABAP Objects, you can only use internal tables without a header line. You can always address the body of an internal table explicitly by using the following syntax: []. This syntax is always valid, whether the internal table has a header line or not.

The COLLECT statement adds the work area or header line to an internal entry with the same type or, if there is none, adds a new entry to the table. It searches for the entry according to the table type and defined key. If it finds an entry in the table, it adds all numeric fields that are not part of the key to the existing values. If there is not already an entry in the table, it appends the contents of the work area or header line to the end of the table.

When you read a table line using READ or a series of table lines using LOOP AT, you can assign the lines of the internal table to a field symbol using the addition ... ASSIGNING <>. The field symbol <> then points to the line that you assigned, allowing you to access it directly. Consequently, the system does not have to copy the entry from the internal table to the work area and back again.
The field symbol <> must have the same type as the line type of the internal table. However, there are also certain restrictions when you use this technique:

You can only change the contents of key fields if the table is a standard table .

You cannot use the SUM statement in control level processing. (The SUM statement adds all of the numeric fields in the work area.)

This technique is particularly useful for accessing a lot of table lines or nested tables within a loop. Copying values to and from the work area in this kind of operation is particularly runtime-intensive. In this example, the user should be able to enter a departure city, for which all possible flights are then listed.
To do this, we decla re an innner table (cofl_list) and an outer table( travel_list) with corresponding work areas.

A further internal table (conn_list) buffers and sorts all of the flight connections.

Note

In order to allow loop access using field symbols, the buffer table and the inner internal table must have the same type. Furthermore, we want to sort the table by various criteria later on. Consequently, we are using standard tables, not sorted tables.

We also need to declare three field symbols with the line types of the internal tables.

Note

It would have been possible to solve this problem using nested SELECT statements. However, this is not a realistic proposition because of the excessive load that we would then place on the database server.

Index access (APPEND, INSERT ... INDEX, LOOP ... FROM TO and so on) is possible for standard and sorted tables. A possible consequence of this is that you may cause a runtime error by violating the sort sequence if you use INSERT with an index or APPEND on a sorted table.

SORT can only apply to standard and hashed tables. It has no positive effect in a sorted table, and can lead to a syntax or runtime error if the attempted sort violates the key sequence.

You can use key access for any table type, but the runtime required varies according to the table type.

The runtime depends on whether the values are part of the key (so the sequence in which you pass them is also significant). INSERT for a standard table or hashed table using the key has the same effect as the APPEND statement.

The system supports control level processing for all table types. Hashed and standard tables must be sorted beforehand.