Wednesday, May 20, 2009

BAPI

A Business Application Programming Interface (BAPI) is a precisely defined interface providing access to processes and data in business application systems such as R/3.

BAPIs are defined as API methods of SAP business object types. These business object types and their BAPIs are described and stored in the Business Object Repository (BOR). A BAPI is implemented as a function module, that is stored and described in the Function Builder.
As of Release 4.5A BAPIs can also describe interfaces, implemented outside the R/3 System that can be called in external systems by R/3 Systems. These BAPIs are known as BAPIs used for outbound processing. The target system is determined for the BAPI call in the distribution model of Application Link Enabling (ALE).


BAPIs used for outbound processing are defined in the Business Object Repository (BOR) as API methods of SAP Interface Types. Functions implemented outside the R/3 System can be standardized and made available as BAPIs. For further information see BAPIs Used For Outbound Processing.

BAPIs can be called within the R/3 System from external application systems and other programs. BAPIs are the communication standard for business applications. BAPI interface technology forms the basis for the following developments:
· Connecting:
· New R/3 components, for example, Advanced Planner and Optimizer (APO) and Business Information Warehouse (BW).
· Non-SAP software
· Legacy systems
· Isolating components within the R/3 System in the context of Business Framework
· Distributed R/3 scenarios with asynchronous connections using Application Link Enabling (ALE)
· Connecting R/3 Systems to the Internet using Internet Application Components (IACs)
· PC programs as front-end to the R/3 System, for example, Visual Basic (Microsoft) or Visual Age for Java (IBM).
· Workflow applications that extend beyond system boundaries
· Customers' and partners' own developments

ALE


Application Link Enabling (ALE) is a set of business processes and tools that allow applications on different computer systems to be linked. This can be done between different SAP systems as well as between SAP and non-SAP systems.
In a single SAP system different applications are integrated via a single database (e.g. finance, sales, production, human resources). However, many companies do not have just one integrated system but a distributed environment with different applications running on different systems. To run the whole business in such an environment the distributed applications have to be linked. This can be done through Application Link Enabling (ALE).
ALE provides distributed business processes that can be used to link the applications on different platforms. There are some ALE business processes delivered in the standard SAP system. Furthermore, there are tools that can be used to change the existing ALE business processes or to implement new distributed business processes.
Besides the business processes there are special ALE services that are required to set up and control a distributed environment. These services include a distribution model, business object synchronization and tools for monitoring or error handling. ALE is a major part of SAP's Business Framework Architecture. Besides the basis middleware, that provides the communication between components, and the interfaces (BAPIs), ALE business processes and ALE services enable the cooperation of the single components within the framework. That makes ALE the glue of the Business Framework

Different types of views

Views:
A view is a logical view on one or more tables, that is, a view is not actually physically stored, instead being derived from one or more other tables.
Types:
Database views
The view defined in the ABAP Dictionary is reproduced in the underlying database. You can use both ABAP Open SQL and ABAP Native SQL to access such views from ABAP programs, but you can only define them using transparent tables. If you define a database view using only one table, you can make changes to the view. For database views containing several tables, however, only read accesses are allowed.
Projection views
Projection views are used to suppress certain fields from a table in the interests of minimizing interfaces. A projection view can only refer to one table and, in contrast to database views, you cannot specify any restrictions with regard to table type. This view type also permits both read and write accesses with ABAP Open SQL.
Help views
Help views are used as the selection method of elementary search helps if the selection is too complex to be defined with a single database table. In contrast to database views, help views implement an outer join. For this reason they are suitable for linking supplementary information such as explanatory text from secondary tables. If the supplementary information were missing in an inner join, the entire dataset would not be selected.
Maintenance views
Maintenance views provide you with a business view of the data. You can change it either with the table maintenance transaction SM30, which allows you to maintain data from the base tables in a view at the same time, or with the customizing transaction. The mechanisms for data maintenance such as screens and processing programs can be created with a special transaction (SE54).

Types of tables in Data Dictionary

Transparent table
There is a physical table on the database for each transparent table. The names of the physical tables and the logical table definition in the ABAP/4 Dictionary correspond.
All business data and application data are stored in transparent tables.
On the other hand, pooled tables and cluster tables are not created in the database. The data of these tables is stored in the corresponding table pool or table cluster. It is not necessary to create indexes and technical settings for pooled and cluster tables.
Pooled table
Pooled tables can be used to store control data (e.g. screen sequences, program parameters or temporary data). Several pooled tables can be combined to form a table pool. The table pool corresponds to a physical table on the database in which all the records of the allocated pooled tables are stored.
Cluster table
Cluster tables contain continuous text, for example, documentation. Several cluster tables can be combined to form a table cluster. Several logical lines of different tables are combined to form a physical record in this table type. This permits object-by-object storage or object-by-object access. In order to combine tables in clusters, at least parts of the keys must agree. Several cluster tables are stored in one corresponding table on the database.

How to Debug a Sap Script ?

They are two ways to debug the SAP Script.
1. Use Tools - Word Processing - Layout Set (SE71). Enter name of layout set and then Utilities - Activate Debugger. It is of no consequence which layout set you enter when selecting the SAP script debugger. (Menu path: Tools-Word processing - Forms, Utilities - Activate Debugger) The next layout set called will invoke the debugger.
2. Another way to set the SAP Script debugger is to run program RSTXDBUG.
When you debug Print program it is same as you debug any other ABAP program. While when you debug SAP Script, you actually debug the code ( scripting) you have written SAP Script Form.In transaction SMARTFORMS look up the name of the generated function module for your smart form. Copy the name and go to transaction SE37. Get into the source code of the function module; via menu Go to -> Main Program and then find your piece of code by SEARCH 'VBELN1 = GS_HD_REF-ORDER_NUMB'. Put a breakpoint there and print your smart form. It will stop at the breakpoint.Script: In SE71 give your form name and in Utilities-->Active debugger.Then put a break point in your print program where ever you want to stop it.After that you need to go to your transaction like VF03/../..Etc for Invoice you need to execute it by giving Output type. Then it will debug step by step .