ABAP BDC and LSMW Comparision

Batch Data Communication (BDC) is the oldest batch interfacing technique that SAP provided since the early versions of R/3. BDC is not a typical integration tool, in the sense that, it can be only be used for uploading data into R/3 and so it is not bi-directional.BDC works on the principle of simulating user input for transactional screen, via an ABAP program. Typically the input comes in the form of a flat file. The ABAP program reads this file and formats the input data screen by screen into an internal table (BDCDATA). The transaction is then started using this internal table as the input and executed in the background.

In Call Transaction・ the transactions are triggered at the time of processing itself and so the ABAP program must do the error handling.It can also be used for real-time interfaces and custom error handling & logging features. Whereas in Batch Input Sessions, the ABAP program creates a session with all the transactional data, and this session can be viewed, scheduled and processed (using Transaction SM35) at a later time. The latter technique has a built-in error processing mechanism too. Batch Input (BI) programs still use the classical BDC approach but doesn't require an ABAP program to be written to format the BDCDATA. The user has to format the data using predefined structures and store it in a flat file. The BI program then reads this and invokes the transaction mentioned in the header record of the file.

Direct Input (DI) programs work exactly similar to BI programs. But the only difference is, instead of processing screens they validate fields and directly load the data into tables using standard function modules. For this reason, DI programs are much faster (RMDATIND - Material Master DI program works at least 5 times faster) than the BDC counterpart and so ideally suited for loading large volume data. DI programs are not available for all application areas.

LSMW is an encapsulated data transfer tool. It can provide the same functionality as BDC in fact much more but when coming to technical perspective most the parameters are encapsulated. To list out some of the differences :

LSMW is basically designed for a fictional consultant who do not do much coding but need to explore the fuctionality while BDC is designed for a technical consultant.LSMW offers different technique for migrating data: Direct input ,BAPI,Idoc,Batch input recording. While bdc basically uses recording.LSMW mapping is done by SAP while in BDC we have to do it explicitly .LSMW is basically for standard SAP application while bdc basically for customized application.Coding can be done flexibly in BDC when compared to LSMW.

BDC and LSMW are the two data migration techniques (from legacy to SAP) . BDC technique is usually done by ABAPers. It consists of three methods.

1) Call Dialog Method
2) Session Method
3) Call Transaction Method


In the case of Session Method , a BDC Session is created , which has the data and info to run it in batch mode. When the user runs this session, every transactions are run in batch mode and tables are updated.
While in call transaction, no session is created. Instead , a report prog is created , which takes input from the file and calls the transaction in Batch mode.

Call dialog method is similar to call transaction, except that updating is done by the calling program itself.This method is obsolete.Advantages of Batch Input Method are

1)Can process large data volumes
2) data integrity is maintained


LSMW and BDC are vastly different.BDC (Batch Data Communication) is a technology used for data transfer. it is meant for transferring data thou SAP transactions itself. when u use BDC for data transfer, the sequence of steps is the same as when u use standard sap transaction screens for data upload. the only difference is that u can use different options for foreground/background processing.

LSMW on the other hand is a tool that helps migrate data from a legacy system (non-sap system ) to SAP system. it offers u various options to use either batch input, direct input, BAPIs or idocs. it involves a series of some 17-18 steps to migrate data.

BDC:
Batch Data Communication (BDC) is the process of transferring data from one SAP System to another SAP system or from a non-SAP system to SAP System.

Features :

BDC is an automatic procedure.
This method is used to transfer large amount of data that is available in electronic medium.
BDC can be used primarily when installing the SAP system and when transferring data from a legacy system (external system).
BDC uses normal transaction codes to transfer data.

Types of BDC :
CLASSICAL BATCH INPUT (Session Method)
CALL TRANSACTION

BATCH INPUT METHOD:

This method is also called as ‘CLASSICAL METHOD’.
Features:
Asynchronous processing.
Synchronous Processing in database update.
Transfer data for more than one transaction.
Batch input processing log will be generated.
During processing, no transaction is started until the previous transaction has been written to the database.

CALL TRANSACTION METHOD :

This is another method to transfer data from the legacy system.

Features:

Synchronous processing. The system performs a database commit immediately before and after the CALL TRANSACTION USING statement.
Updating the database can be either synchronous or asynchronous. The program specifies the update type.
Transfer data for a single transaction.
Transfers data for a sequence of dialog screens.
No batch input processing log is generated.

LSMW:

The LSM Workbench is an R/3-based tool that supports You when transferring data from non-SAP systems ("Legacy Systems") to R/3 once or periodically.The tool supports conversion of data of the legacy system in a convenient way. The data can then be imported into the R/3 system via batch input, direct input, BAPIs or IDocs.Furthermore, the LSM Workbench provides a recording function that allows to generate a "data migration object" in an entry or change transaction.

The main advantages of the LSM Workbench:

• Part of R/3 and thus independent of individual platforms
• A variety of technical possibilities of data conversion:
• Data consistency due to standard import techniques:

Batch input
Direct input

BAPIs (Business Application Programming Interfaces)
IDocs (Intermediate Documents)

The import technique to be used in an individual case depends on the business object.

• Generation of the conversion program on the basis of defined rules
• Clear interactive process guide
• Interface for data in spreadsheet format
• Creation of data migration objects on the basis of recorded transactions
• Charge-free for SAP customers and SAP partners


RELATED LINKS

BDC PART ONE
SAP USER EXITS

Challenges in implementing ERP
ERP implementation practices
Enterprise resource planning introduction

SAP Modifications Extended Lesson Fifty Seven

Modifications can be categorized as 'critical' if:They affect numerous other Repository objects (such as Dictionary objects or function modules) Modification adjustment is either difficult (as with menus, pushbbuttons, and GUI interfaces up to 4.5A) or not supported by a tool (transaction codes, message classes, logical databases).Withbout the Modification Assistant (prior to Release 4.5A), both modifying GUI statuses and GUI titles, as well as assigning customer function modules to SAP function groups, should be considered 'critical' activities.SAP only changes the following Repository objects in an upwardly compatible manner. They should therefore be considered 'uncritical' by customers who want to call them:

Function modules that have been released
BAPIs
Includes for user exits
Screen, program, menu, and field exits

After an upgrade, you must test customer reports that call SAP objects, as well as all objects displayed in the upgrade utility SPAU. This is also true for Repository objects that have been automatically adjusted using the Modifications Assistant .You must be familiar with the processing logic of your application in order to be able to adjust programs properly.Modification adjustment is not necessary if you avoid making changes to SAP objects.Use program enhancements and appends with SAP tables to enhance SAP objects in such a way that your changes cannot be overwritten by SAP at upgrade.From Release 3.0, you can use Online Correction Services to import and cancel Support packages and patches automatically (instead of having to insert preliminary corrections manually).

Modification has the advantage that your live Repository objects do not lose their connection to the SAP standard. Copying, on the other hand, has the advantage that no modification adjustment will be necessary for your live Repository objects during subsequent upgrades.

Choose copying instead of modifying if:

You have to make numerous changes to an SAP program
Your requirements will not be met by the standard in future R/3 releases
During copying, pay attention to a Repository object's environment as well. You should only decide whether to modify or copy after having informed yourself of the consequences for the main program, as well as for all of the includes attached to the main program. The same holds true for function groups and function modules.

ABAP development projects can be evaluated according to the following criteria:

What will implementation cost, measured in manpower (creating the concept, implementation, testing)?
How will the ABAP development project influence:
Production operation performance?
The amount of adjustment at upgrade?
By calling SAP objects in your own Repository object, you can drastically reduce the amount of effort needed to implement your object. However, any changes that SAP makes to the Repository object you choose to call may make extra adjustment necessary after an upgrade. For example, SAP could conceivably change the user interface of a screen for which you have written a batch input program.

Naming conventions allow you to avoid naming conflicts and give your Repository objects meaningful names (that can be understood by others).
The following naming conflicts can occur:
An SAP Repository object and a customer Repository object conflict
SAP Repository objects and customer Repository objects should be separated from each other by strict adherence to SAP naming conventions.

Two customer Repository objects conflict

Naming conflicts can also occur between customers Repository objects in decentralized
Development scenarios where more than one development system is being used. You can avoid naming conflicts in this area by reserving a special namespace for development areas within the customer namespace. The Workbench Organizer checks to make sure that you adhere to these conventions by making entries in view V_TRESN.

RELATED POSTS

LESSON 1 SAP NAVIGATION

SAP Modifications Lesson Fifty Six

An object is original in only one system. In the case of objects delivered by SAP, the original system is at SAP itself. These objects are only copies in customer systems. This applies to your development system and all other systems that come after it.If you write your own applications, the objects that you create are original in your development system. You assign your developments to a change request, which has the type Development/Correction.This request ensures that the objects are transported from the development system into the subsequent systems.Changes to an original are called corrections. They are recorded in a change request whose tasks have the type "Development/correction".

If, on the other hand, you change a copy (an object outside its own original system), the change is recorded in a task with the type "Repair". Repairs to SAP objects are called modifications.When you repair your own objects (for example, if something goes wrong in your production system), you can correct the original in your development system straight away. When you change copies, you must correct the original immediately.However, you cannot do this with SAP objects, because they are not original in any of your systems.

You should only modify the SAP standard if the modifications you want to make are absolutely necessary for optimizing workflow in your company. Be aware that good background knowledge of application structure and flow are important prerequisites for deciding what kind of modifications to make and how these modifications should be designed.Whenever you upgrade your system, apply a support package, or import a transport request, conflicts can occur with modified objects.Conflicts occur when you have changed an SAP object and SAP has also delivered a new version of it. The new object delivered by SAP becomes an active object in the Repository of your system.

If you want to save your changes, you must perform a modification adjustment for the objects. If you have a lot of modified SAP objects, your upgrade can be slowed down considerably.To ensure consistency between your development system and subsequent systems, you should only perform modification adjustments in your development system. The objects from the adjustment can then be transported into other systems.

A registered developer must register registers changes to SAP objects. Exceptions to this registration are match codes, database indexes, buffer settings, customer objects, patches, and objects whose changes are based on automatic generation (for example , in Customizing). If the object is changed again at a later time, no new query is made for the registration key. Once an object is registered, the related key is stored locally and automatically copied for later changes, regardless of which registered developer is making the change. For the time being, these keys remain valid even after a release upgrade.

How do you benefit from SSCR (SAP Software Change Registration)?

Quick error resolution and high availability of modified systems
All objects that have been changed are logged by SAP. Based on this information, SAP's First Level Customer Service can quickly locate and fix problems. This increases the availability of your R/3 system.

Dependable operation
Having to register your modifications helps prevent unintended modification. This in turn ensures that your R/3 software runs more reliably.

Simplification of upgrades
Upgrades and release upgrades become considerably easier due to the smaller number of
modifications.

If you want to change an SAP Repository object, you must provide the Workbench Organizer with the following information:

SSCR key
Change Request

We saw above how you get an SSCR key. If you now continue to change the object, you must confirm the following warning dialogs: At this point, you can still cancel the action without repairing the object.The Workbench Organizer asks you to enter a change request, as it would for your own objects. The object is automatically added to a repair task. The change request has the following functions:

Change lock
After the task has been assigned, only its owner can change the object.

Import lock
The object cannot be overwritten by an import (upgrade or support package).

Versions
The system generates a new version of the object (see below).

After development is finished, the programmer releases the task. At this point, the programmer must document the changes made. The objects and object locks valid in the task are transferred to the change request. If the developer confirms the repair, the import lock passes to the change request. If the developer does not confirm the repair when releasing the task, the import lock remains in place.
Only the developer can release this lock.Once the project is completed, you release the change request. This removes all of the change request's object locks. This applies both to the change locks and the import locks.

When the change request is released, the objects are copied from the R/3 database and stored in a directory at operating system level. They can then be imported into subsequent systems by the system administrator.After the modifications have been imported into the quality system, the developer must test them and check the import log of the request.When you release a change request, a complete version of all objects contained in the change request is written to the versions database.

If you transport the Repository object again later, the current object becomes a Complete copy and the differences between the old and the new object are stored in the versions database as a backwards delta.Whenever you assign a Repository object to a task, the system checks whether the current version agrees with the complete copy in the versions database. If not, a complete copy is created. This process is also initiated the first time you change an object, since SAP does not deliver versions of Repository objects.

The versions of a Repository object provide the basis for modification adjustment. To support adjustment, information on whether the version was created by SAP or by the customer is also stored.Encapsulate customer source code in modularization units instead of inserting it directly into SAP source code (with, for example, customer function module calls in program source code, or customer sunscreen calls for additional screen fields).When encapsulating the customer portions of a program, be sure to use narrow interfaces.You should define a standard for all of your company's modification documentation (see the following slides).You should also maintain a list of all modifications to your system (a modification log - see the following slides).

All requests that contain repairs must be released before an upgrade so that all relevant customer versions can be written to the versions database (the system compares versions during adjustment).Repairs must also be confirmed prior to upgrade, otherwise the object being repaired is locked and cannot be imported.

Any modifications that you make to ABAP Dictionary objects that belong to Basis components are lost at upgrade--- these objects revert to their earlier form and no adjustment help is offered. This can lead to the contents of certain tables being lost.The aim of the Modification Assistant is to make modification adjustments easier. In the past, the granularity of modifications was only at including program level. Today, a finer granularity is available. Now, modifications can be recorded at subroutine or module level.

This is because (among other reasons) the modifications are registered in a different layer. As well as providing finer granularity, this means that you can reset modifications, since the original version is not changed.If, in the past, you modified an include for which SAP provided a new version in an upgrade, a modification adjustment was necessary. The modification adjustment had to be performed line by line. The system provided little support.

The Modification Assistant has changed this situation considerably. Modifications are now recorded with finer granularity. For example, if you modify a subroutine, the rest of the include remains unchanged. If SAP delivers a new version of the include, the system looks to see if there is also a new version of that subroutine. If this is not the case, your changes can be incorporated into the new version automatically.

The original version of each software layer comprises the originals from the previous layer plus current modifications.the ABAP Editor, you can use modification mode to change source code. Only a restricted range of functions is available in this mode. You can add, replace, or comment out source code, all under the control of the Modification Assistant.Changes to layout and flow logic in the Screen Painter are also recorded.

The Modification Assistant also records changes in the Menu Painter and to text elements, as well as the addition of new function modules to an existing function group.To avoid conflicts in the upgrade, table appends are also logged by the Modification Assistant.If you want to change an SAP object, you must provide the following information:

SSCR key

Change request
The system informs you that the object is under the control of the Modification Assistant. Only restricted functions are available in the editor.You can switch the Modification Assistant on or off for the entire system changing the R/3 profile parameter eu/controlled_modification. SAP recommends that you always work with the Modification Assistant.You can switch off the Modification Assistant for single Repository Objects. Once you have done so, the system no longer uses the fine granularity of the Modification Assistant.

In modification mode, you have access to a subset of the normal editor tools. You can access these using the appropriate push buttons. For example, in the ABAP Editor, you can:
Insert

The system generates a framework of comment lines between which you can enter your source code.

Replace
Position the cursor on a line and choose Replace. The corresponding line is commented out, and another line appears in which you can enter coding. If you want to replace several lines, mark them as a block first.

Delete
Select a line or a block and choose Delete . The lines are commented out.

Undo modifications
This undoes all of the modifications you have made to this object.

Display modification overview
Choose this function to display an overview of all modifications belonging to this object.

The graphic shows the result of changes made with Modification Assistant.The Modification Assistant automatically generates a framework of comment lines describing the action. The comment also contains the number of the change request to which the change is assigned, and a number used for internal administration.The "modification overview" icon provides you with an overview of the modifications you have made in the current program.The display is divided up according to the various modularization units. This corresponds to the structure used by the Modification Assistant to record the modifications.You can reset all of the modifications that you have made to the current object using the Modification Assistant by choosing this function. The record of the modifications is also deleted.

Remember that you cannot selectively undo modifications to an object. You can only undo modifications based on the "all or nothing" principle.The Modification Browser provides an overview of all of the modified objects in the system. The Modification Browser differentiates between modifications made with the Modification Browser and those made without.

On the initial screen of the Modification Browser, you can restrict the selection according to various criteria. This allows you to find modifications in a particular area.The Modification Assistant displays the hit list in tree form. Objects are arranged by:

Modification type (with/without the Assistant)

Object type (PROG, DOMA, DTEL, TABL,)

SAP recommends that you use Modification Assistant to make changes to R/3 objects. Changes without the use of the Modification Assistant should be avoided. However, should this be necessary, you should document your modifications in the source code as follows?

Preliminary corrections SAP note, repair number, changed by, changed on, valid until

Customer functions that have been inserted subject area, repair number, changed by, changed on, INSERTION

Customer functions that have replaced SAP functions subject area, repair number, changed by, changed on, REPLACEMENT The SAP functions that you do not need should not be deleted, but commented out instead

Subject areas are specified in the relevant process design blueprint (for example, subject area SD_001 = pricing).

SAP recommends that you keep a record of all modifications that have been made to your system (that is, of any changes you have made to Repository objects in the SAP namespace).

The following information should be logged for each modification:

Object type (program, screen, GUI status,)

Object name

Routine (if applicable)

Subject area (according to process design blueprint or technical design)

Repair number
Changed on
Changed by
Preliminary correction? (Yes/no)
OSS note number, valid until Release x.y

Amount of time necessary to recreate modification during adjustment (measured in hours).
A module pool is organized as a collection of include programs. This is particularly useful for making the program easier to understand. The organization is similar to that of function groups. In particular, the naming convention, by which the last three letters of the name of the include program identify its contents, is identical.The main program, as a rule, contains the include statements for all of the include programs that belong to the module pool.The includes described as "special" includes in the program are themselves only include programs - technically, they are not different. These programs are only delivered once.User exits are a type of system enhancement that were originally developed for the R/3 Sales and Distribution Module (SD). The original purpose of user exits was to allow the user to avoid modification adjustment.

A user exit is considered a modification, since technically objects in the SAP namespace are being modified.The SAP developer creates a special include in a module pool. These includes contain one or more subroutines routines that satisfy the naming convention userexit_. The calls for these subroutines have already been implemented in the R/3 program. Usually global variables are used.After delivering them, SAP never alters includes created in this manner; if new user exits must be delivered in a new release, they are placed in a new include program.User exits are actually empty subroutines that SAP developers provide for you. You can fill them with your own source code.

The purpose behind this type of system is to keep all changes well away from program source code and store them in include programs instead. To this end, SAP developers create various includes that fulfill the naming conventions for programs and function groups. The last two letters in the name of the include refer to the include that the customer should use: "Z" is usually found here.Example: Program SAPM45A Include M45AFZB

This naming convention guarantees that SAP developers will not touch this include in the future. For this reason, includes of this nature are not adjusted during modification upgrade.The subroutine call is already implemented in the program. The interface is already defined. Normally, subroutines of this type only work with global data.If any new user exits are delivered by SAP with a new release, then they are bundled into new includes that adhere to the same naming convention.There, you will also find documentation explaining why SAP developers have created a particular user exit.

The set of objects for adjustment is derived from the set of new objects delivered by SAP in a new release. This is compared with the set of objects you have modified on your R/3 system.The intersection of these two sets is the set of objects that must be adjusted when you import an upgrade or support package.During modification adjustment, old and new versions of ABAP Repository objects are compared using transactions SPDD and SPAU.You do not have to call transaction SPDD to adjust Dictionary objects if:

No changes have been made to SAP standard objects in the Dictionary
You have only added customer objects to your system. Only SAP objects that have been
Changed must be adjusted using this transaction.

All other ABAP Repository objects are adjusted using transaction SPAU. Upgrade program R3up tells you to start the transaction after upgrade has finished. You have 30 days to use transaction SPAU after an upgrade. After 30 days, you must apply for a SSCR key for each object that you want to adjust.

Transaction SPAU first determines which objects have been modified. Then it determines which of these objects have a new version in the current upgrade. Modification adjustment allows you to transfer the modifications you have made in your system to your new R/3 Release.Use transaction SPDD to adjust the following ABAP Dictionary objects during the modification adjustment process:

Domains
Data elements
Tables (structures, transparent tables, pool, and cluster table, together with their technical settings)
These three object types are adjusted directly after the Dictionary object import (before the main import). At this point in time, no ABAP Dictionary objects have yet been generated. To ensure that no data is lost, it is important that any customer modifications to domains, data elements, or tables are undertaken prior their generation.

Changes to other ABAP Dictionary objects, such as lock objects, match codes, or views, cannot result in loss of data. Therefore, these ABAP Dictionary objects are adjusted using transaction SPAU after both main import and object generation have been completed. You can use transaction SPAU to adjust the following object types:

ABAP programs, interfaces (menus), screens, match code objects, views, and lock objects.During modification adjustment, you should use two different change requests to implement the changes you have made: one for SPDD adjustments and another for SPAU adjustments. These change requests are then transported into other R/3 systems you want to adjust. This guarantees that all actual adjustment work takes place solely in your development system.

When upgrading additional R/3 systems, all adjustments exported from the first system upgrade are displayed during the ADJUSTCHK phase. You decide which adjustments you want to accept into your additional systems and these are then integrated into the current upgrade. Afterwards, the system checks to see if all modifications in the current R/3 system are covered by the change requests created during the first system upgrade. If this is the case, no adjustments are made during the current upgrade.

Note: For this process to be effective, it is important that all systems involved have identical system landscapes. This can be guaranteed by first making modifications in your development system and then transporting them to later systems before you upgrade the development system. You can also guarantee that all of your systems have an identical system landscape by creating your development system before upgrade as a copy of your production system and then refraining from modifying the production system again until after upgrade.Version compare is also used during or after an upgrade for modification adjustment.

During modification adjustment, version compare determines the number of SAP objects that you a) changed in the system and that b) were then overwritten by SAP at upgrade.Version compare allows you to find where changes were made and transfer them to your new SAP version if you want.The icons in front of the individual objects that need adjustment show how they can be adjusted.The possible methods are:

Automatically
The system could not find any conflicts. The changes can be adopted automatically

Semi-automatically
The individual tools support you in adjusting the objects.

Manually You must process your modifications with no special support from the system. In this case, the modification adjustment does allow you to jump directly into the relevant tool. Adjusted objects are identified by a green tick. If you want to use the new SAP standard version, use Restore original. If you do this, you will have no further adjustment work in future.

RELATED POSTS

LESSON 57 MODIFICATIONS EXTENDED


Check Deposit Customization

Business Add Ins in SAP ABAP Lesson Fifty Five

A class is an abstract description of an object. Each object only exists while the program is running.In this unit, when we talk about objects, we may actually mean the abstract description (the class), depending on the context.An object is described by its class and consists of two layers - an inner and an outer layer.Public components: The public components are those components of the class (for example,attributes and methods) that is visible externally. All users of the class can use the public components directly. The public components of an object form its interface.

Private components: These components are only visible within an object. Like the public components, the private components can be attributes and methods.The aim of object orientation is to ensure that a class can guarantee its own consistency.Consequently, the data of an object is normally "internal", that is, represented using private attributes. The internal (private) attributes of a class can only be changed by methods of the class.As a rule, the public components of a class are methods. The methods work with the data in the class and ensure that it is always consistent.

Objects also have an identity to differentiate it from other objects with the same attributes and methods.Until Release 4.0, the nearest thing to objects were function groups and function modules.When you call a function module, an instance of its function group - with all of its data definitions is loaded into the memory area of the internal session. An instance is a real software object. An ABAP program can therefore load instances of different function groups by calling function modules, but only one instance of each function group can exist at a time.

The principle difference between real object orientation and function modules is that a program can work with instances of different function groups, but not with several instances of a single function group. For example, suppose a program wanted to manage several independent counters, or several orders at the same time. If we did this using a function group, we would have to program an instance management to differentiate between the instances (using numbers, for example).In practice, it is very cumbersome to implement instance management within a function group.

Consequently, the data is usually in the calling program, and the function modules work with this data. This causes various problems. For example, all of the users have to work with the same data structures as the function group. If you want to change the internal data structure of a function group, you will affect a lot of users, and the implications of the changes are often hard to predict.Another problem is that all users have copies of the data, and it is difficult to keep them consistent when changes are made.Working with global data in function groups is dangerous, because it is almost impossible in a complex transaction to control when each function group is loaded.

These problems have been solved with the introduction of classes. Data and functions are defined in classes instead of function groups. An ABAP program can then work with any number of run time instances that are based on the same template. Instead of loading a single run time instance of a function group implicitly when you call a function module, ABAP programs can create run time instances of classes explicitly. The individual run time instances are uniquely identifiable objects, and are addressed using object references.Interfaces are defined independently of classes.They can contain declarations for elements such as attributes and methods.Interfaces are implemented by classes.The classes then have a uniform external point of contact. They must provide all of the functions of the interface by implementing its methods.In a program, you can create reference variables with reference to interfaces. However, you cannot instantiate an interface.Interface references can, however, point to objects of different classes.

Business add-ins, unlike customer exits, takes into account the changes to the software delivery process. The top part of the graphic illustrates the typical delivery process: It no longer merely consists of software provider and end user. Instead, it can now contain a whole chain of intermediate software providers like SAP Industry Solutions (IS) and partners.

Below this is a diagram explaining how business add-ins work. Enhancements are made possible by SAP application programs. This requires at least one interface and an adapter class that implements it. The interface is implemented by the user.The main advantage of this concept is the capacity for reuse. Once implemented, a business add-in can be reimplementation by other links in the software chain.

Furthermore, an implementation can also offer business add-ins of its own.A business add-in contains the components of an enhancement. Currently, each business add-in can contain the following components:

Program enhancements

Menu enhancements

In future releases, the other components included in customer exits will also be available as add-in components.Several components are created when you define a business add-in:

Interface
Generated class (add-in adapter)
The generated class performs the following tasks:

Filtering: If you implement a filter-dependent business add-in, the adapter class ensures that only the relevant implementations are called

Control: The adapter class calls the active implementations.


In the first step, an existing service class, CL_EXITHANDLER, creates an object reference. We will discuss the precise syntax later on. This completes the preparations for using the program enhancement.

When you define a business add-in, the system generates an adapter class, which implements the interface. In call (2), the interface method of the adapter class is called. The adapter class searches for all of the implementations of the Business Add-In and calls the implemented methods.This graphic contains the syntax with which you call a business add-in. The numbered circles correspond to the calls from the previous page.First, you must define a reference variable with reference to the business add-in interface. The name of the reference variable does not necessarily have to contain the name of the business add-in.In the first step (1), an object reference is created. This creates an instance of the generated adapter class, restricted to the methods of the interfaces ("narrowing cast").

You can use this object reference to call the required methods (2).There are various ways of searching for business add-ins:

You can search in a relevant application program for the string "CL_EXITHANDLER". If a business add-in is called from the program, the "GET_INSTANCE" method of this class must be called.You can then reach the definition of the business add-in using forward navigation. The definition also contains documentation and a guide for implementing the Business Add-In.However, you can also use the application hierarchy to restrict the components in which you want to search. Start the Repository Information System, then choose Environment -> EXIT techniques -> Business Add-Ins" to start the relevant search program.Alternatively, you can use the relevant entries in the IMG.

To implement business add-ins, use transaction SE19 (Tools -> ABAP Workbench -> Utilities -> Business Add-Ins ->Implementation).Enter a name for the implementation and choose Create. A dialog box appears. Enter the name of the business add-in. The maintenance screen for the business add-in then appears.

Alternatively, you can use the Business Add-In definition transaction to reach its implementations.The menu contains an entry "Implementation", which you can use to get an overview of the existing implementations. You can also create new implementations from here.You can assign any name to the implementing class. However, it is a good idea to observe the proposed naming convention. The suggested name is constructed as follows:

Namespace prefix, Y, or Z
CL_ (for class)
IM_ (for implementation)
Name of the implementation

To implement the method, double -click its name. The system starts the Class Builder editor.When you have finished, you must activate your objects.In the implementing class, you can create your own methods that you then call from the interface method.You cannot create them using forward navigation. Instead, you must define a regular method in the Class Builder (along with its interface). Specify a visibility for the method, and implement it.

Use the "Activate" icon to activate the implementation of a Business Add-In. From now on, the methods of the implementation will be executed when the relevant calling program is executed.If you deactivate the implementation, the methods will no longer be called. However, the corresponding calls in the application program are still processed. The difference is that the instance of the adapter class will no longer find any active implementations. Unlike the "CALL CUSTOMER-FUNCTION" call, the "CALL METHOD CL_EXITHANDLER=>GET_INSTANCE" call is still executed even if there are no implementations. The same applies to the statement calling the method of the adapter class.

You can only activate or deactivate an implementation in its original system. Changing it anywhere else constitutes a modification. The activation or deactivation must be transported into subsequent systems.If a business add-in can only have one implementation; there can still be more than one implementation in the same system. However, only one can be active at any time.As with customer exits, you can use menu enhancements with Business Add-Ins. However, the following conditions must be met:

The developer of the program you want to enhance must have planned for the enhancement.

The menu enhancement must be implemented in a BAdI implementation.

Function codes of menu enhancements begin with a plus sign '+'.

The menu entry will only appear if there is an active business add-in implementation containing the corresponding enhancement.You can only create function codes for business add-ins that can only be used once. Moreover, the business add-in cannot be filter-dependent.These restrictions are necessary to ensure that there are no conflicts between two or more implementations.If the user chooses the menu entry in the program to which the function code "+" is assigned, the system processes the relevant method call.

The method call and the menu enhancement belong inseparably to one another. Having the former without the latter would make no sense. For this reason, it is important that the two enhancement components are combined in a single enhancement - the business add-in.To create a BAdI, use the BAdI Builder (Tools -> ABAP Workbench -> Utilities -> Business Add- Ins -> Definition).

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 uses, 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 consist 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 is 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.


RELATED POSTS

LESSON 56 SAP MODIFICATIONS
SAP Financial and Controlling Complete Lessons

BusinessTransaction Events in ABAP Lesson Fifty Three

Compared with earlier releases, the software delivery process now looks quite different. Previously, only two parties were involved in the delivery: SAP produced the software, and delivered it to its end-customers. Customers could enhance this standard using customer exits.However, now that the software is more component-oriented, more parties have become involved in the process: SAP provides the R/3 standard to each SAP Industry Solution, which uses it as a basis to add on its own encapsulated functions. The next link in the chain might be a partner firm, which builds its own Complementary Software Program (CSP) solution based on R/3. The last link in the chain is the customer, as before.

All of the parties involved in this process are potential users and providers of enhancements. This requirement cannot be satisfied by customer exits, which can only be used once. Consequently, SAP developed a new enhancement technique in Release 4.0, which allows enhancements to be reused.Business Transaction Events (BTE) allow you to attach additional components, in the form of a function module, for example, to the R/3 system.

Business Transaction Events use one of the following types of interfaces:

Publish & Subscribe interfaces
These interfaces inform external software that certain events have taken place in an SAP standard application and provide them with the data produced. The external software cannot return any data to the R/3 System.

Process interfaces

These interfaces are used to control a business process differently than the way in which it is handled in the standard R/3 System. They intervene in the standard process, and return data to the SAP application.You can attach various external developments to the R/3 System. You can create additional developments using the ABAP Workbench.The example above pertains to Publish & Subscribe interfaces. In this case, data only flows in one direction - from the SAP application to the additional component.SAP application developers make interfaces available to you at certain callup points in a transaction.You can deposit additional logic at these points.

In a very basic scenario, SAP partners and customers can use the interfaces themselves. In this case business transaction events function in much the same manner as customer exits (see the unit on "Enhancements using Customer Exits").



In contrast to customer exits, business transaction events allow you to use an interface for multiple types of additional logic.If this is the case, you must decide which bit of logic you want to execute at what time.Both of your enhancements exist side by side with out impeding each other; however, at runtime only one of the enhancements can be processed.

Publish & Subscribe interfaces:

Allow you to start one or more (multiple) additional operations when a particular event is triggered. They do not influence the standard R/3 program in any way.Multiple operations do not interfere with each other.Add-on components can only import data.Possible uses: Additional checks (authorizations, existing duplicates, and so on)

Process interfaces:

In contrast to Publish & Subscribe interfaces, data exchange takes place in both directions with process interfaces. This influences the number of additions that can be attached to the interface.When an event is triggered, a process in the standard program can only be replaced by a single external process using the process interface.

If you are using an add on from an SAP partner that uses a process interface, this enhancement is processed at run time. If you choose to use this same process interface for one of your own developments, the partner enhancement is dismissed and your own enhancement is processed at run time instead.

The graphic shows the flow of an SAP program. The program contains an enhancement in the form of a Business Transaction Event. The program calls a service function module, which determines and processes the active implementation of the enhancement. The naming convention for these function modules is OPEN_FI_PERFORM__E (or OPEN_FI_PERFORM__P).

This function module determines the active implementations for each enhancement and stores them in an internal table. The implementing function modules are processed in the sequence defined by the internal table. At this point the system also considers the conditions under which the function module will be processed in the customer namespace - for example, the country or application. These conditions are also shown as filter values.

In the SAP application program, a function module is called with the name "OPEN_FI_PERFORM__E" (or, for process interfaces, "OPEN_FI_PERFORM__P").The application program passes data to the service function module using the interface. SAP developers have already designed the interface.The service function module searches for active implementations and places them in an internal table. They are then processed in a loop.

Business transaction events allow you to implement additional logic in a task function, similar to function module exits. SAP application programmers determine where to place business transaction events in a task function and what data should be transferred at each point.

First, SAP application programmers assign a business transaction event an eight digit number by which it can be identified. These numbers should observe a particular convention. For example, the fifth and sixth digits should be identical with events in the same program.The SAP developer registers the event and creates a template function module,sample_interface_ , which establishes the interface for the user.

To find out directly whether an application transaction offers business transaction events, you can use the procedure described on the left-hand side of the graphic. In the program source text, search for the character string "OPEN_FI_PERFORM". The number that completes the name of the function module is also the name of the event.

In the SAP Customizing Implementation Guide (IMG), you will find the entry "Use business transaction events " under the "Financial Accounting Global Settings" node of the Financial Accounting area. Choosing this entry calls a transaction (FIBF) where you can execute all of the actions necessary for using Business Transaction Events.

Under Environment, you will find search functions that you can use to identify appropriate business transaction events. You can view the documentation for the event from the list.The "Environment "menu of the service transaction FIBF contains two programs that you can use to search for BTEs. You can restrict the search by using various parameters.The BTEs that the system finds are displayed in a list. You can then:

Display the model function module (start the Function Builder and copy it, for example)

Display the interface

Display the documentation



Use service transaction FIBF to create a product. A product groups together a collection of enhancements.You can create products for various layers in the delivery chain. They define a sequence for processing the implementations of a business transaction event.You can only switch each product on or off as a whole entity. This allows the user to control which enhancements should be processed and which should not. It also ensures the integrity of the whole enhancement.

You can use the transaction FIBF (called when you selected "Use business transaction events" from the financial accounting hierarchy) to carry out all necessary activities prior to using a business transaction event.First, you must choose an interface to attach your function module to. The Interface button displays the parameter structure for the interface you have selected. You can also use the documentation to determine what functions each interface allows you to perform.

Use the ABAP Workbench to copy the sample function module sample_interface_ to the customer namespace (z_*) of a customer function group. You must not change the interface. You can fill the module with any source text except COMMIT WORK. Don't forget to activate the function module.

Create a product in transaction FIBF.

Assign a number to your function module and product.
In contrast to customer exits, business transaction events are client-specific. This means that the same event can be used in different clients for different purposes.
Business transaction events may also be used more than once.

With Publish & Subscribe interfaces, you can choose which enhancement you want to use.With process interfaces, the system executes a single component in the hierarchical sequence SAP application, add on, customer.

RELATED POST

LESSON 54 ENHANCEMENTS USING CUSTOMER EXITS
My SAP Project safety and security

Enhancement using Customer Exists Lesson Fifty Four

Application enhancements allow customers to enhance their application functions. Customer exits are preplanned by SAP and generally consist of several components.Application enhancements are inactive when delivered and can be completed and activated by customers as they are needed.Application enhancement characteristics:

Each enhancement provides you with a set of preplanned, precisely defined functions.

Each interface between SAP and customer functions is clearly defined.

As a customer, you do not need in-depth knowledge of how to implement SAP applications.

You do not need to adjust enhancements at upgrade because of new functions that SAP has developed.

The SAP application programmer creates SAP enhancements from function module exits, menu exits and screen exits. A management function is provided for this purpose (transaction code SMOD).Customers are given a catalog containing an overview of existing SAP enhancements. They can then combine the SAP enhancements they want into an enhancement project using transaction CMOD.

SAP enhancements are made up of component parts. These components include function module exits, menu exits, and screen exits. A specific component may be used only once in a single SAP enhancement (this guarantees the uniqueness of SAP enhancements).

Customer enhancement projects consist of SAP enhancements. Each individual SAP enhancement may be used only once in a single customer enhancement program (this guarantees the uniqueness of a customer project).

The SAP application programmer plans possible application enhancements in an application and defines the necessary components. These components are combined in SAP enhancements.The programmers document their enhancements as best they can, so that customers can implement the enhancements without having to analyze program source code or screen source code.

First, create an enhancement project and then choose the SAP enhancements that you want to use.Next, edit your individual components using the project management function and document the entire enhancement project.Finally, activate the enhancement project. This activates all of the project's component parts.

Transaction CMOD starts the project management function. You must give your enhancement project a name. SAP recommends that you think up a naming convention for all of your projects.You can, for example, include the project's transaction or module pool in its name. All enhancement project names must be unique.

Next, go to the project's attributes and enter a short text describing the enhancement project. The system inserts the entire project's other attributes (such as created by, created on, or status).Use the project management function to assign SAP enhancements to customer enhancement projects. Enter the names of the SAP enhancements you want to use on the appropriate screen.The search function gives you a catalog-like overview of existing SAP enhancements. From there you can select those enhancements that are of interest to you.

Use the product management function to edit the components of your enhancement project.Depending on whether the component you are editing is a function module, a menu entry, or a SUB SCREEN, you branch to either the Function Builder, a dialog box for entering menu entries, or to the Screen Painter.

Activation of an enhancement project affects all of its components. After it has been activated successfully, the project has the status active.During activation, all programs, screens, and menus containing components that belong to the project are regenerated (programs at the time they are executed). After activation, you can see the effect of the enhancements in your application functions.The Deactivate function allows you to reset an active enhancement project's status to inactive.

When the enhancement project was created; you should have assigned it to a change request. Each of the component pieces (include programs, SUB Screens, menu exits, and so on) should be assigned to the same change request. Using the same change request allows you to transport the entire enhancement at the same time.

Function module exits allow customers to implement additional logic in application functions. SAP application programmers define where function module exits are inserted and what kind of data they transfer. SAP programmers also create an exit's corresponding function modules complete with short text, interface, and documentation, as well as describing each function module exit's intended purpose in the SAP documentation.

You write the source code for the function modules yourself. If need be, you can also create your own screens, text elements, and includes for the function group.The system processes your ABAP code when the enhancement project (of which your function module is a component) is activated. Function module exits have no effect prior to enhancement project activation.This graphic shows the flow of a program providing an enhancement in the form of a function module exit.

The exit function module is called in the PAI logic of a screen at a position determined by the SAP application developer. Within the function module, the user can add functions in the customer namespace using an include.SAP application programmers use the ABAP statement CALL CUSTOMER-FUNCTION 'nnn' to call function modules, where nnn is a three-digit number. (Where 'nnn' is a three-digit number). The application programmer must also create the function module he wants to call and its related function group.These function modules belong to function groups whose names begin with X (X function groups).

The following naming convention applies to these function modules:

Prefix: EXIT
Name: name of the program that calls the function module
Suffix: three-digit number
The three parts of the name are separated by two underscores.

The CALL CUSTOMER-FUNCTION statement is only executed if the enhancement project has been activated. Multiple calls of the same function module are all activated at the same time.The most frequently asked question concerning enhancements is: how can you see if an application program offers a function module exit? There are a number of ways to find the answer to this question.

To see quickly if an application program offers a function module exit, you can follow the path on the left-hand side of the graphic: (The menu path System Status always displays the name of the current application program). In our example a suitable character string would be "CALL CUSTOMER". Use the Find icon and search globally in the program. If your search does not provide any results, you can define a larger search area. Determine the environment for the corresponding program and look for the specific character string in the program environment.

The right side of the graphic shows you how to find the name of the required enhancement using search tools. You can restrict the search in the R/3 Repository Information System using different criteria: These are:

Development class (also try generic entries)

Technical name of the enhancement

Use the project management (transaction: CMOD) function to edit function modules for function module exits.Use the button for editing components to go directly to the function module editor (display mode).

DO NOT change the function module itself. It is especially important that you do not alter the interface in any way. The function module, however, contains an INCLUDE statement for an include program that you have to create in the customer namespace.Double-click on the include name beginning with ZX. This automatically takes you to the editor of the include program, where you can enter your code.

To understand how an X function group works, you need to understand how a normal function group works:

A function group consists of includes. The system assigns unique names to the includes for different objects. Some of the include names are simply proposals and some cannot be changed.Global data is stored in the TOP include. This include is generated automatically when a function group is created.Function modules are stored in includes with sequential numbering, and they in turn are all stored in an include ending with UXX.You can freely choose the names of the includes for all other objects (subroutines, modules, events, etc.). However, we advise you to accept the proposed names.

Exit function groups created by SAP application programmers for enhancement exits contain include programs that begin with either 'LX' or 'ZX'. You can only edit includes beginning with a 'Z', since they are stored in the customer namespace.No further function modules may be added to the function group.The include program ZxaaaUnn contains the source code for the function modules of a function module exit.

SAP application programmers can declare global data in include program LXaaaTAP.You can declare your global data in include ZXaaaTOP.Include program LXaaaTOP also contains the FUNCTION-POOL statement, which may not e changed. Therefore, you must always include the message class in parentheses when outputting messages - for example, MESSAGE E500 (EU).The INCLUDE statement for program ZXaaaUnn is in a FUNCTION - ENDFUNCTION block.Because of this, neither events, nor subroutines (FORM), nor modules (MODULE) are allowed here.

They can, however, be created in separate includes, which is explained later. Data declarations made here with DATA are valid locally in this function module.The SAP application programmer can also make a proposal for the source text. In this case, an INCLUDE LXaaFnn is created (where nn is the internal number for the function module in the include LXaaaUXX). Documentation is also provided within the SAP enhancement. You can copy the source code from this include into your own customer include program ZXaaaUnn using the project management transaction.You can create your own text elements for the function group.SAP applications programmers can supply you with default subroutines in include LXaaaF01.

There could be further includes containing specific sub-objects.

LX...F01 contains subroutines delivered by SAP.

LX...E01 contains the events belonging to the X function group.

LX...O01 contains PBO modules for screens to be delivered.

LX...I01 contains the corresponding PAI modules.

Subroutines, modules, and interactive events (AT…) are created as include programs and included enhancements using include program ZXaaaZZZ.Additional includes must adhere to the following naming convention:

ZXaaaFnn for subroutines,

ZXaaaOnn for PBO modules,

ZXaaaInn for PAI modules,

ZXaaaEnn for events.

You can use CALL SCREEN to call your own screens. Create the related include programs for the PBO and PAI modules in include program ZXaaaZZZ.Use forward navigation (select an object and then double -click on it) to create your own screens and modules.Screens created in this manner are automatically given the name of the function module's main program (SAPLXaaa). The PBO modules for these screens can be found in include ZXaaaO01, the PAI modules in include ZXaaaI01.You can enhance SAP applications by adding your own processing logic at predefined points.

Such enhancements can include your own screens with their corresponding processing logic and graphical user interface, as well as text elements created by customers.Menu exits allow you to attach your own functions to menu options in SAP menus. SAP application programmers reserve certain menu entries in your GUI interface for this. This allows you to define a text for the reserved menu entry and add your own logic, often in the form of a related function module exit. Once you activate menu exits, they become visible in the SAP menu. Whenever this menu option is chosen, the system processes either a function provided by SAP application programmers or your own function that you have implemented in a function module exit.

In order for you to be able to implement menu exits, SAP application programmers must equip the GUI interface with function codes that begin with a plus sign ('+').These function codes are inactive at first and do not appear in the GUI until you have activated them. They do not appear on the screen.Menu exits are edited with the project management transaction (CMOD).

The push button for editing components calls a dialog box where you can enter short descriptions and choose a language for each additional menu entry.You may not make any changes to the GUI interface.SAP application programmers determine where a program reads additional function codes and how it reacts--- either with a function module exit or with a predefined function.

You can implement menu exits based on reserved function codes. The SA P application programmer defines the relevant function codes, assigns them to menus, and often provides a function module exit.Menu exits and function module exits are both part of the same SAP enhancement.No pushbuttons may be assigned to additional function codes.You can, however, make changes to the various menu entries and activate their function codes.

Screen exits allow you to make use of reserved sections of a main screen (SUB SCREEN areas). You can either display additional information in these areas or input data. You define the necessary input and output fields on a customer screen (SUB SCREEN).

SUB SCREENs are rectangular areas on your screen that are reserved for displaying additional screens at runtime. Each SUB SCREEN area can be filled with a different screen (of type SUB SCREEN) at run time.The R/3 System determines which screen will be displayed in a SUB SCREEN area at PBO. 

<sub>The SAP application programmer can reserve multiple SUB SCREEN areas for a screen.
The SUB SCREEN is called during flow control of the main screen with the CALL CUSTOMERSUB SCREEN statement. The name of the SUB SCREEN area must be defined without apostrophes. The function group to which the SUB SCREEN belongs is defined statically in apostrophes, but the screen number can be kept variable by using fields; it must always have four places.Screen exit calls are inactive at first, and are skipped when a screen is processed.

Only after a corresponding SUB SCREEN has been created in an enhancement project, and this project has been activated, will the system process the screen exit.You create SUB Screens in X function groups. Normally, these function groups also contain function module exits.Whenever the statement CALL CUSTOMER-SUB SCREEN INCLUDING occurs at PBO in the flow control of a screen, a SUB SCREEN is included in the SUB SCREEN area defined by SAP application programmers. At this point, all modules called during the PBO event of the SUB SCREEN are also processed.The PAI event of a SUB SCREEN is processed when the calling screen calls the SUB SCREEN during its PAI event using the statement CALL CUSTOMER-SUB SCREEN .

The global data of the calling program is not known to the X function group that contains your SUB SCREEN; SAP application programmers use function module exits to explicitly provide this data to SUB Screens.In order to facilitate data transport, modules is called in the flow control of the calling program that contains function module exits for transferring data via interface parameters.Function modules belonging to these kinds of function module exits can be found in the same function groups as their corresponding SUB Screens.

Data must be transported in the other direction as well, since global data from the X function group that contains your SUB SCREEN is not known to the calling program either. For this reason, SAP application programmers use function module exits to return any data to the calling program that was changed in the SUB SCREEN.This is done by calling a module during the main screen's PAI event that contains a function module exit for returning customer data via interface parameters.

SUB Screens are edited with the project management transaction (CMOD).The technical names of screen exits consist of the name of the calling program, a four-digit screen number, and the name of the SUB SCREEN area, followed by the name of the X function group's program and the number of the SUB SCREEN.You must create the SUB SCREEN as well as the corresponding PBO and PAI modules. The SAP development environment supports creation with forward navigation.Make sure that your SUB Screens are of screen type SUB SCREEN the first time you create them.You are not allowed to change any of the interfaces in the X function group that the SUB SCREEN and the function module exits belong to, nor are you allowed to add any of your own function modules.


Screen exits allow you to determine the layout of certain portions of a screen yourself. You can use these areas to display additional information, or to collect and process data.Screen exits must be predefined (planned) by an SAP application programmer. Use the statement CALL CUSTOMER-SUB SCREEN to integrate these preplanned SUB SCREEN areas into the flow control of the calling screen at PBO and PAI events.As soon as you activate an enhancement project that contains a SUB SCREEN as a component, the calling screen is regenerated and the SUB SCREEN is displayed the next time the application function is called.


RELATED POSTS

LESSON 55 BUSINESS ADD IN'S</sub>
SAP project introduction in the best ERPSAP project migration

Enhancements to Dictioanry Elements in ABAP Lesson Fifty Two

Tables and structures can be expanded in one of two different ways:

Append structures allow you to enhance tables by adding fields to them that are not part of the standard. With append structures; customers can add their own fields to any table or structure they want.Append structures are created for use with a specific table. However, a table can have multiple append structures assigned to it.If it is known in advance that one of the tables or structures delivered by SAP needs to have customer-specific fields added to it, the SAP application developer includes these fields in the table using a Customizing include statement.The same Customizing include can be used in multiple tables or structures. This ensures consistency in these tables and structures whenever the include is extended.

Nonexistent Customizing includes do not lead to errors.Append structures allow you to attach fields to a table without actually having to modify the table itself.Append structures may only be assigned to a single table. A table may, however, have several append structures attached to it. Whenever a table is activated, the system searches for all active append structures for that table and attach them to the table. If an append structure is created or changed and then activated, the table it is assigned to is also activated, and all of the changes made to the append structure take effect in the table as well.

You can use the fields in append structures in ABAP programs just as you would any other field in the table.If you copy a table that has an append structure attached to it, the fields in the append structure become normal fields in the target table.You create append structures in the customer namespace. This protects them from being overwritten at upgrade or during release upgrade. New versions of standard tables are loaded during upgrades.

The fields contained in active append structures are then appended to the new standard tables when these new standard tables are activated for the first time.From Release 3.0, the field sequence in the ABAP Dictionary can differ from the field sequence in the database. Therefore, no conversion of the database table is necessary when adding an append structure or inserting fields into an existing one. All necessary structure adjustment is taken care of automatically when you adjust the database catalog (ALTER TABLE). The table's definition is changed when it is activated in the ABAP Dictionary and the new field is appended to the database table.

Pay attention to the following points when using append structures:

You cannot create append structures for pool and cluster tables.If a table contains a long field (either of data type LCHR or LRAW), then it is not possible to expand the table with an append structure. This is because long fields of this kind must always be the last field in their respective tables. No fields from an append structure may be added after them.

If you use an append structure to expand an SAP table, the field names in your append structure must be in the customer namespace, that is, they must begin with either YY or ZZ. This prevents naming conflicts from occurring with any new fields that SAP may insert in the future.

Some of the tables and structures delivered with the R/3 standard contain special include statements:

Customizing includes. These are often inserted in those standard tables that need to have customer specific fields added to them.

In contrast to append structures, Customizing includes can be inserted into more than one table. This provides for data consistency throughout the tables and structures affected whenever the include is altered.

Customizing include programs is part of the customer namespace: all of their names begin with 'CI_'. This naming convention guarantees that nonexistent Customizing includes do not lead to errors. No code for Customizing includes is delivered with the R/3 standard.

You create Customizing includes using special Customizing transactions. Some are already part of SAP enhancements and can be created by using project management (see the unit on 'Enhancements using Customer Exits').

The Customizing include field names must lie in the customer namespace just like field names in append structures. These names must all begin with either 'YY' or 'ZZ'.

When adding the fields of a Customizing include to your database, adhere to same rules you would with append structures.

Every time they define a data element, the SAP application programmers define keywords in different lengths and a short description for each data element.

You create field exits in Project management. Field exits are processed when the user leaves a screen that contains a field which refers to a data element containing a field exit.

SAP lets you create a field exit for every input-ready screen field that has been created with reference to the ABAP Dictionary. The additional program logic is stored in a function module and is executed at a specific point in the PAI logic.

The slide shows the order in which processing takes place. Before the PAI logic of the screen is executed, the system performs the following checks: First the system checks if all the required fields have been filled in. If a required field is empty, the screen is shown again.

The system then checks that data has been entered in the correct format.

Any defined field exits are executed next. For example, by sending an error message you can have the screen sent again.

Once all the field exits have been checked, the screen is processed as normal.

Field transport
Foreign key check
Processing the PAI module

Field exits take you from a screen field with a data element reference to a function module. Field exits can be either global or local:

Global field exits are not limited to a particular screen: If a global exit's data element is used on several screens, the system goes to the function module for all these screens after activating the field exit. Here you can, for example, edit the contents, force a new entry to be made by outputting an error message, or prohibit certain users from proceeding further.

Local field exits are valid for one screen only. If you assign a screen from a specific program to a field exit, then the system will go to the appropriate function module from this screen once the exit has been activated.

You can either create a global field exit or up to 36 local field exits for a data element, but not both.Each exit number refers to a different function module. Field exit function modules adhere to the following naming convention:

Prefix: FIELD_EXIT_
Name:
Suffix (for local field exit): _0 to _9, _A to _Z
To create field exits; choose Utilities in the ABAP Workbench. Choose Enhancements and then Project management to edit field exits and to implement customer exits. Do not create field exits directly from the Function Builder.

Choose Goto -> Global enhancements -> Field exits to start the transaction for maintaining field exits. To create a new enhancement, use the menu path Text Enhancements -> Create.Enter the name of the data element to which your screen field refers in the modal dialog box. The Function Builder is started with a special naming convention and interface options. The system specifies the name of the field exit. Do not change this name. Create the function module in a customer function group.The function module must be assigned to an existing customer function group.

The function module interface is fixed and cannot be changed. The function module has an import parameter INPUT and export parameter OUTPUT. The contents of the screen field are stored in parameter INPUT. The contents of OUTPUT are returned in the screen field when you leave the function module.

Field exits are not transported automatically. Therefore, you must assign the value of INPUT to OUTPUT in your source code. Otherwise the screen field would be blank after executing the field exit.The following ABAP statements are not allowed in field exit function modules:

CALL SCREEN, CALL DIALOG, CALL TRANSACTION, SUBMIT
COMMIT WORK, ROLLBACK WORK
COMMUNICATION RECEIVE
EXIT FROM STEP-LOOP
MESSAGE I, MESSAGE W
STOP, REJECT

When you debug a screen that is referenced by a field exit, the field exit code is ignored by the debugger. As with any normal function module, you can, however, debug the field exit code in the Function Builder's test environment.You can create local field exits that relate to a specific screen. A global field exit must already exist.Edit the local field exit based on the global field exit.You can create up to 36 local field exits, each of which carries a unique suffix. The system proposes a name for the function module; you should use this name.

Defining local field exits means that the function module of the global field exits initially created is no longer used. However, you must not delete it, for technical reasons. The field exits in the system would be deleted if you deleted the global function module of the field exit from the list.You must activate the field exit as well as the function module. Also note that field exits are only taken into account during screen execution if the R/3 profile parameter abap/field exit = YES has been set for all application servers. (This profile parameter is set to 'NO' by default).

If you declare field exits for multiple screen fields, you have no control over the order in which they are processed. In particular, you cannot access the contents of other screen fields in a field exit.


RELATED POSTS

LESSON 53 BUSINESS TRANSACTION EVENTS
MySAP environment security solutions
SAP security authentication and authorization