Explore topic-wise InterviewSolutions in .

SCENARIO 1:

Consider that you have got a Business Requirement that says, “It requires a control at the Production Order level”, which implies that when a sales order has been created, the creation of a production order will also take place based on the sales order values. This needs to be stopped for various business reasons. There is no standard functionality available where the functional user will be able to configure this in SAP.

The current open sales order at the production level should not be hot by the process. ABAPer has to MAKE a checkpoint creation for the business where the quantity will be approved by the Manager, which needs to be produced based on the sales order.

You need to code at numerous user exits and a custom table should be created that populates all the details of sales orders and restricts the user authority only for the approval authority like Manager. It has to perform the quality checks multiple TIMES before we finally decide for moving the code into production.

SCENARIO 2:

Generally, when the creation of a sales order takes place, the sales order gets BLOCKED based on the credit check or credit limit(if activation was done by the functional consultants) of the customer. So, you need to ‘unblock’ the sales order even if the customer has been EXCEEDED the credit limit depending on CERTAIN conditions.

For this scenario, you need to write code at numerous places, during the time of the creation of sales orders and also during the delivery time. This process is known as enhancements.

So, for ABAPers the constant evolution of SAP coding standards for core ABAP must be the same, but the methodologies and techniques of implementation or workarounds will be evolving.

There are 3 FUNCTIONAL modules used in a sequence for SUCCESSFULLY performing the TRANSFER of data in BDC(Batch Data Communication) programming. They are:

• BDC_OPEN_GROUP : Parameters such as CLIENT name, user name, sessions, etc., will be specified in this functional module.
• BDC_INSERT : It is used for inserting the data for a single transaction into a session.
• BDC_CLOSE_GROUP : It is used for closing the batch INPUT session.

Enhancement framework in SAP ABAP is the new modification-free enhancement concept that allows you for adding functionalities to standard SAP software without modification of original repository objects. It also helps the consultants, customers, and third parties by providing an option of ENHANCING the standard code with custom code that they WISH to add.

The below diagram shows the enhancement framework options.

The enhancement framework is divided into two parts. They are:

• IMPLICIT Enhancements: In the ABAP report, enhancements are possible by default at two places, the start of the report and the end of the report. So, customers are able to do enhancements at the beginning and end by creating enhancement implementations by default in all the reports.
• EXPLICIT Enhancements: The places in the report will be explicitly provided by the SAP where EXACTLY it can be enhanced. There are three options available under these explicit enhancements:
  • Enhancement Point: It will be created in the report where exactly the customer can enhance so that the expected RESULTS at that point can be modified using enhancement implementations.
  • Enhancement Section: It will be created in the report by selecting the code section that can be enhanced using customer implementation.
  • BAdi: It is MAINLY used for ABAP Objects where a BAdi definition creation can be done using an interface with a fixed signature which can be implemented by the customer using the BAdi implementation.

A view is a virtual table that consists of fields from one or more TABLES. There are 4 types of VIEWS in SAP ABAP. They are:

• Projection View: It is used to hide specific fields in a given table and can also be used to gain access to the cluster, pooled, and transparent tables. Selection conditions are not available in a projection view. The projection view access will be through an Open SQL, not Native SQL.
• Help View: It is used in the search helps. The search help is able to select database views, database tables, and special help views. For database views, the search help is RESTRICTED to the inner joins and for database tables, it is restricted to a single table. It is not possible to define a help view in the database.
• Database View: It is a general view used for single or multiple basis tables. Once the database view is activated, multiple basis tables can be joined with an inner join by creating a matching SQL view. It is possible to access database views using both Open SQL and Native SQL.
• Maintenance View: It performs writes on different tables using EXTENDED table maintenance. One maintenance view is capable of CHANGING the contents of many related database tables unfailingly. The maintenance view cannot be accessed using Open SQL.

IDoc(Intermediate Document) is an SAP OBJECT that carries business transaction DATA in the form of ELECTRONIC messages from one system to another. The IDoc HELPS for transferring data/information from the SAP system to other SYSTEMS and vice versa. The data transfer between two SAP systems is accomplished by using ALE(Application Link Enabling) and data transfer from SAP system to non-SAP system is accomplished using EDI(Electronic Data Interchange) subsystems.

Report Programs in ABAP are event-driven programs that are used for displaying a large amount of data. The various events firing will take place in a particular ORDER within a report program. That is:

• Top of page: This event will be triggered by the first ‘write’ statement written in the report. It acts as a page header. By default, the first event triggered will be the ‘load-of-program’, if the ‘write’ statement is not INCLUDED in the report.
• Load-of-program: This event will be triggered when the program of type E(Executable program), M(Module pool), F(Function pool), or S(Subroutine pool) gets loaded. It will be in existence only once per program.
• Initialization: This event is used for initializing the values. This event will be triggered after the ‘load-of-program’ event and before the display of the selection screen.
• At selection-screen output: This event will be triggered just before the display of the selection screen. It is used if you wish to change the screen fields during runtime. It will hide the fields or make them invisible/visible or make them intensified.
• At selection-screen: This event will be triggered processing of selection-screen by the USER. It will be used for checking and validating the inputted values.
• At selection-screen on field: This event will be triggered in the PAI(Process After Input) when data is transferred from PARAMETERS or SELECT-OPTIONS to ABAP. It can be used for validating the user input.
• At selection-screen on value-request: Using this, if a program field is defined with ABAP Dictionary field reference for which possible entries help has been defined, the values from the ABAP Dictionary help will be displayed automatically on calling F4 help for that field by the user.
• Start-of-selection: This event will be triggered on execute button click or F8 button press by the user.
• End-of-selection: This event will be triggered on the execution of the last statement of the start-of-selection event.
• End of page: This event will be triggered each time when the list data reaches the page footer region.

Multiple inheritances mean where multiple classes can be a superclass of a single class. ABAP objects don’t SUPPORT multiple inheritances as we can’t INHERIT a class from more than one class. It allows defining a class INHERITING from only a single class in ABAP objects. If you are trying to DEFINE multiple superclasses during class definition, an error message will be prompted by the compiler. But still, you can accomplish a similar functionality like multiple inheritances by using Interfaces in SAP ABAP.

• Adobe forms is a technology used for developing the forms and now it has become the current standard in SAP for form development. To use these forms, a Java stack must be first installed in SAP Basis. ALONG with that, developers need to configure the Adobe Document Service(ADS). Adobe LiveCycle DESIGNER(LCD), GUI(graphical user interface) for Adobe Forms- must also require to be installed separately as the application will run on Windows.
• Using Adobe Forms, we can create the forms in companies, fill out the form, output as a print form, show it as a PDF file on screen, or even it can be sent. Such forms will include purchase orders, orders, and invoices.
• From the SAP SYSTEM, it reads the associated master data and transaction data. The data will be displayed by the application in the predefined and desired form, for EXAMPLE, as a print form. Entering data in forms is also allowed.
• Adobe has become the successor to SAPscript and SmartForms. This technology has surpassed its two predecessors SAPscript and SmartForms in various areas like performance and design.
• We can SEPARATE design and programming by using Adobe forms in SAP. Also, Interactive Forms by Adobe in SAP provides different suitable tools and functions for the easier design of a form.
• It is possible to customize the forms by form developers with the help of their own programming by using two script languages Adobe FormCalc or JavaScript. The developer tool for Adobe Forms will be accessed through SFP(SAP tcode-Form Builder) transaction.

• OSS(Online Service System) notes are a part of an online SAP service portal that GIVES up-to-date information about SAP notes. It is the Knowledge Base of SAP that will address the known issues specifically in the SAP system. It FREQUENTLY releases patches, new program DEVELOPMENTS, bug fixes, and other various updates by SAP. This will provide a list of correction notes for SAP objects.
• OSS Notes will be continuously UPDATED as customers report issues in the SAP system and SAP will release a note that includes detailed instructions about fixing or addressing the issue. Most of the issues get addressed or fixed when the next version of the same component gets RELEASED by SAP and hence it is very important to see note applicability related to the version where an issue is being addressed. Each note will be applied to a version and almost all its predecessor versions. Before you start with your work, it is necessary to check for the presence of a particular in your SAP system.

• Transport Requests(TRS) are a ‘Container or Collection’ type of change that can be done in the development system. Also, the INFORMATION related to the requested category, type of change, the target system, and the purpose of transport will be recorded. Transport requests are also called Change Requests.
• Every transport request will have multiple(one or more) change jobs(change Tasks). Tasks will be stored INSIDE a TR, in the same way as multiple files will be stored in some folder. TR will be released only once after the completion/release/deletion of all the tasks inside a TR.
• Change Task is an object list that has gone through a modification by a specific user. Each task must be assigned to(and released by) a SINGLE user only. Anyways, multiple users will be assigned with each Transport Request. Tasks cannot be transportable by themselves, it can be done only as a PART of TR.

The SAP ABAP 3-tier architecture has 3 major layers. They are:

• Presentation Layer: It is an interface or program known as “sapgui.exe” installed on a PC or Workstation of a user. This interface will accept user inputs in the form of mouse clicks, function keys, or keystrokes and will send the request that NEEDS to be processed by the application server. The application server will send the result back to the interface and output formatting will be done in order to display it to the user.
• Application Layer: This is an executable set that togetherly does ABAP/4 program interpretation and will also be able to do input/output MANAGEMENT for them. When the application server gets started each and every executable will get started at the same time and when the application server stops, they shut down together. The details about the number of the process that began during the starting of the application server will be specified in a single configuration file known as Application Server PROFILE. The application server is in existence for interpreting and running the ABAP/4 programs. It is possible for an ABAP/4 program to start an executable on the presentation server but the execution of them is not possible. When an ABAP/4 program makes a request for the data from the database, then that request will be formatted by the application server, and finally, the formatted request will be sent to the database server.
• Database Layer: This is an executable set that will accept requests for the database that came from the application server. The requests will be passed on to the database, it will be processed and information will be sent back to the database server, from there it will be later passed on to the application server. The application server will pass on this database RETRIEVED information to the ABAP/4 program.