ABAP Enhancement Technologies

Enhancing Standard SAP ABAP code

SAP has already provided certain solutions for the standard SAP processes. But sometimes there is a need of adding some additional logic to change the business logic according to user needs or change the look and feel of some standard screens. When we try to change certain standard code the system asks us to provide access key for which one has to register him. Actually there is no need of doing so as SAP provides source code plugins where one can add his/her own logic.

SAP provides many ways to achieve it.

1.       User Exit ( Generally only for SD module)

2.       Customer Exit (For MM, SD, PP, FICO modules)

3.       Enhancement framework

4.       BAdI (OOPs concept)

1.       USER EXIT

User Exit is implemented in the form of subroutine also known as FORM EXITs. The user exits are generally collected in includes and attached to the standard program by the SAP. User-exits are empty subroutines and one can fill them with your own source code. Technically this is a modification.
E.g.
FORM USEREXIT_XXXX....
 INCLUDE ZZUSEREXIT.......
  ENDFORM.   

 All of the user exits in SD are contained in the development class VMOD.

How to find these:

SE80- Give package name as VMOD.

These are the includes for user exits for sales order, delivery, billing, pricing etc. One can write his own logic inside a include program and put that include inside the subroutine meant for the exit of the include for user exit.

2.       Customer Exit

These are mainly of three types:

a.       Field Exit

b.      Function Module Exit

c.       Screen Exit

d.      Menu Exit

There are two important TCodes namely SMOD (To find available Exits) and CMOD (To implement the Exit).

a.       Field Exit

These can be created in two ways

i.                     Go to transaction CMOD and there execute transaction PRFB in command line.

ii.                   Use program RSMODPRF to create it.

By both the ways one has to provide the Field Element and Screen number and a Function module named as FIELD_EXIT_ is generated with data element as import parameter. The validation logic is written inside the function module.

b.      Function Module Exit

One can find the available function module exit from SMOD and use it in his own code. Actually the Function Module exit is a function module with a Z include. One can write his own logic inside this. This is called using CALL CUSTOMER-FUNCTION ‘<3 digit="" number="">’. But the actual Function module name is EXIT_SAPLSUSF_<3 digit="" number="">.

c.       Screen Exit

Standard screen modifications are achieved through this exit. Standard screen are modified by placing special sub screen areas on standard screen and calling the sub screen from standard screen flow logic.

CALL CUSTOMER_SUBSCREEN INCLUDING

In PAI of main screen the PAI of sub screen is called using

CALL CUSTOMER_SUBSCREEN .

To transfer data from screen to sub screen or vice versa two function module exits are used.

d.      Menu Exit

Using this any user specific menu item can be added to the standard menu options. To use this first one has to find the package in which the menu program is written and then from there one has to find the available exits using package name in SMOD. Then using CMOD one can achieve his desired results.

3.       Enhancement Framework

Enhancement can be of two types.

a.       Implicit Enhancement

b.      Explicit Enhancement

a.       Implicit Enhancement:

In an ABAP report/Function Module SAP provided implicit enhancement points i.e. at the beginning and end of the codes. So customer can do customer implementations at these places.

Implicit enhancements are possible at-

                                         I.            Beginning/End of Include/Function Module/Routine

                                       II.            End of structure

                                     III.            End of private/public/protected section of a local class.

b.       Explicit Enhancement:

These are explicitly declared. These can be of two types:

                                      I.            Enhancement Point

                                    II.            Enhancement Section

Enhancement Point: These are created in the report where exactly customer can enhance in future to get some of the additional checks/logics to get desired results. Customer adds logic at the point using enhancement implementation.

After a standard code is generated for functionality the cursor is kept at a point where enhancement logic can be written in future to enhance the logic further. Then from the Edit option – Enhancement Operations, enhancement option can be created. That time enhancement point name and enhancement spot name are given.

Then when the customer wants to add his own logic ,he goes for enhancement implementation by choosing edit option after choosing enhance option from program option.

Enhancement Section:  Enhancement section is created around a section of code which can be enhanced later by customer/partner. Enhancement section creation and implementation is same as enhancement point creation and implementation. After implementation the new set of code replaces the old code in the logical flow sequence.

               

4.               BADI

BADI is the object oriented enhancement technique in SAP ABAP. BADI definition created with an interface with fixed signature that can be implemented by the customer. During development phase an enhancement spot is created from SE18 and BADI definition is created inside it. An interface separately created added to it. BADI is called from the program using GET BADI and CALL BADI method. Customer creates BADI implementation from SE19 using BADI interface.

A program can have multiple BADIs inside it. To find the required BADI, put a breakpoint in GET_INSTANCE method class CL_EXIT_HANDLER and execute the transaction.

After application developer creates an interface for the business add in, enhancement management takes this interface and generates an adapter class for implementing it. So developer has to create an instance of adapter class in the application program while implementing the BADI.

Introduction to IDOC interface

Introduction to IDOC interface.

The main objective of an implementation of SAP R/3 ERP is to group all the functions of a company together in a single system. But it is almost impossible to hold all data related to an organization in a single system due to load balancing, task segmentation and risk distribution. So the data stored in different landscapes and mostly in different heterogeneous systems. To communicate through all these distributed heterogeneous systems SAP has designed its own communication tool.

Application Linking and Enabling (ALE) is a technology to create and run distributed applications. ALE is proprietary of SAP. Through ALE controlled exchange of data messages occurs, it also ensures data consistency across loosely coupled applications. ALE communication occurs from SAP side and EDI (Electronic data interchange) from the non-SAP side. ALE supports fail safe delivery which means the sender system does not worry about message not reaching the source due to unavoidable situations. The message is exchanged in the form of IDOC (Intermediate document which contains application data).

An IDOC is created as a result of execution of outbound ALE (Going to other system) whereas in inbound ALE (Coming in from other System) an IDOC serves as an input to create application data.

An IDOC can be generated at any point of transaction. After a user performs a transaction one or more IDOC can be generated in the sending database and passed to the ALE layer. The ALE communication layer performs RFC check through port definition and RFC destination specified in customer model and then IDOC is transmitted to the receiver.

Every IDOC has exactly one control record along with a number of data records and status records.

Prerequisite before IDOC data processing.

1.  Create Segments (WE31) and release them – Adding fields from a table or structure

2.       Create Basic IDOC type by assigning several segments (WE30).

3.       Create message type (WE81) and assign basic type to message type (WE82).

4.       Define Logical System (SALE).

5.       Maintain RFC destination (SM59) and test remote login using target system details.

6.       Define Ports (WE21).

7.       Maintain distribution model (BD64).

8.       Generate client profile (BD82/WE20) and assign RFC system, Target System and message type.

9.       Distribute model view (BD64).

Sender System /Outbound Programming.

1.       Fetch Data from data base table in to internal table.

2.       Fill the control record of EDIDC type. (Control record contains message type, basic type, RFC port, Partner type, Partner number)

3.       Fill data record of EDIDD. (Fill segments and pass segment to data record)

4.       Call function module MASTER_IDOC_DISTRIBUTE and pass control record structure and data record table.

5.       Commit work.

Receiver System /Inbound Programming.

1.       Create a FM and include MBDCONWF which has predefined ALE constants.

2.       The FM has import the EDIDD type data table and updates DDIC table.

3.       Fill and export status record of type BDIDCOSTAT.

4.       The function module is assigned to logical message (WE57).

5.       Input method for Inbound FM is set in BD51 and process code in WE42.

Message type gives the meaning of the IDOC. IDOC type indicates the SAP format that is to interpret the data of a business transaction. There are certain standard message types which we normally use. They are:

1.       MATMAS – Material Master

2.       CRMAS – Vendor Master

3.       COND_A - Condition Record

4.       INFREC - Info Record

5.       SRCLST – Source List

Interface Programming Steps:

1.       Application Document created when a transaction is saved

2.       Message control is invoked

3.       Message processed by system

4.       ALE/EDI Output is checked

5.       Validated against message control record from partner profile.

6.       Application document is saved

7.       NAST table entry created

8.       Processing program is determined

9.       Read partner profile and get process code

10.   Invoke FM of process code

11.   IDOC generated and saved in database

12.   In the receiving system EDI system creates IDOC from Edi message

13.   FM EDI_DATA_INCOMING is called

14.   Control record validated

15.   IDOC generated and through process code Application document posted

What shall I do when I get an IDOC error?

1.       Go to transaction WE02 and enter IDOC number (Remove date if date is not known)

2.       Go to the third section of the IDOC i.e. status record.

Some popular status message numbers are:

53- Success

51- Error

12- Dispatch OK

68- Unnecessary IDOC

03- Passed to port

3.       Copy the message number and paste it in SE91 to know the error details.

4.       Check partner profile in WE20, double click message type and go to process code, Search error message and put a break point.

5.       Go to BD87, enter IDOC number, execute, select error message, process.

Inbound IDOC can be selected and executed through WE19. There are few programs through which outbound IDOCs can be processed. They are:

Ø  RBDAGAIN – Process outbound IDOC with error

Ø  RBDAGAIE  - Reprocess edited IDOC

Ø  RBDAGAI2 – Reprocess after ALE input error

To trace IDOC of the receiving system from sending system, execute BD87 and note start & end time for  IDOC execution  and for the respective message type trace it. To trace IDOC based on data, go to WE09 and use message type, segment name, field name. Use search value in value field and execute.

Miscellaneous:

         IDOC information gets stored in

1.       EDIDC – Control Record

2.       EDID4 – Data record

3.       EDIDD – Data Segment

4.       EDIDS – Status Record

         Message type gives the meaning of the IDOC whereas IDOC type indicates the SAP format that is to be interpreting the data of a business transaction.

         Process code refers to the workflow or the function module which helps in reading or writing data from/to IDOC. Outbound process code read application data and places the same in IDOC. Inbound process code read IDOC and create application data.

Scenario:  Consider a scenario where you want to send material master from one system (SYS A) to another system (SYS B). The standard IDOC for material master is MATMAS.

1.      Outbound processing-

You need to send the material master (MATMAS) from SYS A to SYS B. For sending this IDOC there is a standard program RBDSEMAT (Tcode: BD10). If we need to send some data for which there is no standard IDOC available we need to create a new IDOC and do coding for sending it. Here we use WE82 for outbound message type & WE41 for outbound process code. We can use program RBDMIDOC to generate master IDOCs & communication IDOCs. We can also use program RSEOUT00, to trigger IDOC manually after collecting IDOCs. We can use RBDAPP01 to trigger IDOC in background.

2.      Inbound processing –

When the MATMAS IDOC comes in the receiving system (SYS B), that master data needs to be created (posted) in the receiving system. For that a function module will be there. For custom IDOC we need to create the function module to post. When we receive IDOC from our customer, & we need to convert IDOC into application document. Suppose think that we received ORDERS05 which is a standard IDOC, this will be posted as purchase order in ME22N.Here we use WE81 for inbound message type & WE42 for inbound process code.

3.      Change pointers –

In some scenarios we need send to the IDOC only if the master data changes. For sending when the master data changes we use program RBDMIDOC. This is known as triggering through change pointers.

4.      distribution model –

Suppose we want to send changes in material master to different clients, that we will do by defining a customer distribution model (BD64) & define all clients here. We use t/codes

BD61 (Activate change pointers globally)

BD50(Activate  change pointers for a message type)

BD52(Activate  change pointers for fields)

& at-last run program RBDMIDOC to distribute IDOCs to these clients.

OOP in ABAP (Part1 – Concepts)

Why to go for object oriented programming from traditional coding?

-          Faster development and maintenance

-          Simplified modeling of the process

-          Reusability of code

OO extension to ABAP is available from release 4.5.

Here the ABAP programs are organized as collections of objects. Objects are the instances of classes. Class is a template for set of objects which share common structure and common behavior.

Classes can be created in se24 which serves as a global class. Classes also can be created inside ABAP program which are local to the program. A class has mainly three sections namely private (accessible only within the class), public (can be accessed outside the class – global data) and protected (can only be accessed by itself and its subclass). Each section can have attributes (data), methods (behavior/functionality), events, exceptions.

Main OOPS concepts are:

1.       Abstraction :

Simplifying the complex reality by modeling in to classes appropriate to the problem.

Classes are to be created only with essential characteristics which distinguishes it from others.

2.       Encapsulation :

It’s a protective wrapper which prevents the code and data from arbitrary access by other code outside of wrapper. Objects are made up of attributes and methods. The publicly defined attributes and methods acts as an interface, which objects can be accessed outside. The private section is used to keep data and methods to keep it safe from random access. The actual implementation is encapsulated means invisible from outside and cannot be accessed directly; the public interface determines how other objects can interact with it.

3.       Inheritance:

It is the method by which a class can get the attributes and behavior from a predefined class.

The inherited subclass can also have its own attributes and behavior along with its parent super class’s attributes and behaviors.

4.       Polymorphism

Ability of objects belonging to different data types to respond to method calls of methods with same name, each one according to an appropriate type specific behavior.

Instance Attribute VS Static Attribute:

There exist only one instance attribute for each instance of a class and there exist one static attribute/class data per each class. Normally static attributes contains information which is applicable to all instances such as types, constants, administrative information, central data etc.

Instance Method, Static /Class Method and Functional Method:

Instance method can access both static and instance components whereas static method can only access static components.  Also for static method access there is no need of instance which means it can directly assess through the class. Method which has a returning parameter is termed as functional method. This can’t have exporting and changing parameter. It follows pass by value.

Constructor and Class Constructor:

Constructor is a special method whose name is always CONSTRUCTOR. It is used to instantiate the object. It is always defined in public section and it can have only importing parameters and exceptions. Whenever an object is instantiated using creates object statement, system creates an object and then it calls the CONSTRUCTOR. When exceptions are raised instances are not created so no memory space is allocated. Whereas class constructor is a static constructor which automatically gets accessed when the system accesses the class for the first time. Static constructor can’t have any parameters and exceptions. It can’t be called explicitly.

Instance Events and Class Events:

Both instance events and static events can be triggered in instance methods but static methods can only trigger static/class events. An event can be public/private/protected. The event handler can have the same visibility or restricted visibility than the event to which it refers. Whenever an event is triggered then the corresponding handler methods that are registered to it are called in sequence.

Abstract Class, Final class and Friend Class:

Abstract class can’t be instantiated. Abstract class should contain at least one abstract method (method without implementation). The subclass of abstract class can be instantiated if they are not abstract. Final class can’t be inherited further. All methods of final class are inherently final. Final method can’t be redefined further. If a method in a class is final then that class can be inherited but the method can’t be redefined. Therefore to restrict the functionalities from changes the method can be made as final. To access the public and protected attributes/methods of one class without inheritance , FRIENDS addition can be used for the class definition of a class  with the name of the other class whose components needs to be accessed. An interface can also be made friend to a class. The inherited subclass of a class which is used as friend for another class, are by default becomes friends of the class.

Narrowing Cast VS Widening Cast:

Narrowing cast/ Up cast refers to assigning the instance of a subclass back to the instance of a super class meaning we are going from a more specific view of an object to less specific view. The opposite is widening cast or down cast.

Exceptions Handling:

Exception refers to a situation that arises while a program is being executed, when there is no point in continuing to run the program in normal way. Class based exceptions are raised by RAISE EXCEPTION statement or by runtime environment. Whenever an exception is raised an exception object is created whose attribute hold the error situation. Try End try block is used to declare a protective section in the code where one can catch one or more exceptions using CATCH statement. When more than one exception is triggered they must be caught in specific generic class sequence order else system generates error message saying ‘Declare exceptions in ascending order’. All exceptions are inherited from class CX_ROOT which has certain predefined methods such as GET_TEXT, GET_SOURCE_POSITION which are inherited by all exception classes.

When an exception is raised the normal program flow is interrupted by system and it tries to navigate to suitable handle which if not found a runtime error occurs. Try- End try block can be nested. There is a CLEAN UP statement within this block which is used to remove the references before leaving the method.

CX_ROOT has three immediate subclass to one of which the exceptions normally refer. They are

1.       CX_STATIC_CHECK

This type of exception has to be explicitly defined in the method signature.  If not declared, it has to be caught else it will result in to run time error. Compiler can identify this type of exception so if declaration or catching is missed then it shows a warning.

2.       CX_DYNAMIC_CHECK

This type of exception has to be explicitly defined in the method signature.  If not declared, it won’t get checked in runtime.

3.       CX_NOCHECK

These must not be declared. If declared gives syntax error.

MM & SD Module Introduction (Technical Prospective)

MM & SD Module Introduction (Technical Prospective)

When there is a requirement of some material or service from a User, then the user inquires whether that is available with the company’s internal resource or not. When the material/service is not available, then the responsible person of the company finds a vendor who can provide the same. If the buyer and vender agree upon the deal then the material/service is purchased from the Vendor and payment processing is done for the Vendor.

MM Module is basically Purchasing/Procuring the material/Service.

The main steps of MM are as follows:

1.       Determine the requirement.

Whenever there is any requirement of material/service an INTERNAL PURCHASING DOCUMENT called as PURCHASE REQUISTION (ME51N) is created which is used to give notification to the responsible department about the requirement. This document also keeps the track of the requirement.

2.       Determine the Source.

Potential source of supply should be determined (ME57).

3.       Vendor Selection.

After determining the potential sources, invitations are sent to prospective vendors for bidding. The invitation document is an external purchasing document and is termed as REQUEST FOR QUOTATION (RFQ - ME41) which requests the vendor to provide a quotation which contains information about price, delivery conditions, payment terms etc.

Then the RFQs are compared to choose the vendor (ME47T).

4.       Purchase Order Processing.

When the vendor agrees upon the RFQ then a purchase order is issued by the company to the vendor. PURCHASE ORDER (PO - ME21N) is a legally binding document which contains information such as description, quantity, date of delivery, agreed price, terms of delivery, and terms of payment. When vendor provides partial delivery partial GR posting is done.

5.       Purchase order follow-up.

6.       Goods Receipt and Inventory management.(MIGO)

When the vendor delivers the material or performs the service, the responsible person of the company performs GR transaction which will update the PO history which in turn increases the material stock level in the inventory.

7.       Invoice Verification.(MIRO)

After the vendor delivers the material/service, the vendor sends an invoice to the company. Invoice is a formal document issued by vendor to company to request for payment for the material/service. It is normally attached with the GR document.

8.       Payment Processing.

When Invoice Receipt (IR) is posted to MM the PAY TO partner of the PO is credited with the amount.  Payment Posting is done in FI module where the vendor’s account payable is debited and the corresponding bank account is credited.

Few MM tables are as follows –

·         MAKT - Material description

·         MARA -  General Material data

·         MARC - Plant data

·         MARD - Storage Data

·         MSEG – Material document  segment

·         MVKE – Sales data for material

·         EBAN – Purchase Requisition

·         EKKO – Purchase Document Header

·         EKPO – Purchase Document Item

·         LFA1 – Vendor master

·         T024 – Purchase Group

·         T023 – Material Group

SD Module refers to Sales and Distribution.

The main steps of SD are

1.       Inquiry       (IN - VA11).

Customer inquiries about the products/ services provided by a company.

2.       Quotation (QT - VA21).

Company provides quotation for products/services to customers.

3.       Sales Order (OR - VA01).

Customer gives a purchase order to the company against which a sales order is raised to customer.

Tables VBAK and VBAP contains sales document header and item data. These also contain enquiry and quotation data. These gets distinguished using field VBTYP (Document Type: Enquiry A, Quotation B, and Order C).

4.       Delivery     [ (LF – VL01)  Picking VL36, Packing VL02, Shipping VT01]

It includes picking, packing, post goods issue, shipment. Company sends material after picking it from the inventory and packing it in handing unit and issues the goods.

Delivery data are stored in LIKP and LIPS.

Delivery and sales tables are related as follows:

LIPS-VBBEL = VBAK-VBELN.

LIPS-VGPOS = VBAP-POSNR.

5.       Billing          (MN - VF01, VF21).

Company bills to the customer for the deliveries and an FI accounting document is created.

Billing data are stored in VBRK and VBRP.

The table relation is as follows:

VBRP-AUBEL = VBAK-VBELN.

VBRP-VGBEL = LIKP-VBELN.

Apart from this conditions for transaction are stored in KONV. Pricing conditions are stored in KONH and KONP. Shipping data are stored in VTTK. Inbound Delivery (Vendor Delivery for incoming goods or returned or rejected delivery) transaction: VL31N/VL10B. Outbound Delivery (Picking, Packing, Goods Issue) transaction: VL01N/VL10A.

Organizational structure for reference :