BDC for SAP

BADI and Customer exits

2009-01-20T07:16:00.000-08:00

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

As with customer exits two different views are available:

1·In the definition view, an application programmer predefines exit points in a source that allow specific industry sectors, partners, and customers to attach additional software to standard SAP source code without having to modify the original object.
2· In the implementation view, the users of Business Add-Ins can customize the logic they need or use a standard logic if one is available.

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

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

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

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

Related Posts:

Customer Relationship Management and mysap an introduction

CRM Management and sales and service strategy of mysap crm

MySAP CRM and customer as business partner

How Customer Relationship management makes company Leader

CRM Uses and how to get best results with CRM

CRM software solutions and mysap advantage

MySAP CRM and customer relationship management

My SAP CRM , Business Scenarios and SAP Solutions

Business View and Mysap.com

Customer Relationship Management Software and Interaction with Customer

Challenges in implementing ERP

ERP implementation practices

Enterprise resource planning introduction

ERP software selection

ERP implementation process and advantages

ERP advantages and erp project launch

BAPI SAMPLE CODE FOR FLAT FILE

2008-08-11T06:32:00.000-07:00

REPORT ZBAPI.

DATA: BEGIN OF i_data OCCURS 0,
text(255),
END OF i_data.

DATA: i_ekko TYPE bapiekkoc.

DATA: it_ekko LIKE TABLE OF i_ekko INITIAL SIZE 0 WITH HEADER LINE.

DATA: BEGIN OF i_ekpo OCCURS 0,
po_item(5),
pur_mat(18),
plant(4),
net_price(23),
disp_quan(13),
END OF i_ekpo.

DATA: it_ekpo LIKE TABLE OF bapiekpoc INITIAL SIZE 0 WITH HEADER LINE .

DATA: BEGIN OF i_eket OCCURS 0,
po_item(5),
deliv_date(8),
quantity(13),
END OF i_eket.
DATA: it_eket LIKE TABLE OF bapieket INITIAL SIZE 0 WITH HEADER LINE.

DATA: v_index TYPE i.
DATA: return TYPE TABLE OF bapireturn INITIAL SIZE 0 WITH HEADER LINE.
DATA: po_num(10).

START-OF-SELECTION.

CALL FUNCTION 'UPLOAD'

EXPORTING
CODEPAGE = ' '
FILENAME = ' '
FILETYPE = ' '
ITEM = ' '
FILEMASK_MASK = ' '
FILEMASK_TEXT = ' '
FILETYPE_NO_CHANGE = ' '
FILEMASK_ALL = ' '
FILETYPE_NO_SHOW = ' '
LINE_EXIT = ' '
USER_FORM = ' '
USER_PROG = ' '
SILENT = 'S'
IMPORTING
FILESIZE =
CANCEL =
ACT_FILENAME =
ACT_FILETYPE =

TABLES
data_tab = i_data

EXCEPTIONS
CONVERSION_ERROR = 1
INVALID_TABLE_WIDTH = 2
INVALID_TYPE = 3
NO_BATCH = 4
UNKNOWN_ERROR = 5
GUI_REFUSE_FILETRANSFER = 6
OTHERS = 7

.
IF sy-subrc 0.

MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

ENDIF.

loop at i_data.
if i_data-text(1) = 'H'.
shift i_data-text.
v_index = v_index + 1.
split i_data-text at ',' into i_ekko-doc_type
i_ekko-purch_org
i_ekko-pur_group
i_ekko-vendor.
append i_ekko to it_ekko.

elseif i_data-text(1) = 'I'.
shift i_data-text.
split i_data-text at ',' into i_ekpo-po_item
i_ekpo-pur_mat
i_ekpo-plant
i_ekpo-net_price
i_ekpo-disp_quan.
append i_ekpo.
move-corresponding i_ekpo to it_ekpo.
append it_ekpo.
clear it_ekpo.
else.
shift i_data-text.
split i_data-text at ',' into i_eket-po_item
i_eket-deliv_date
i_eket-quantity.

append it_eket .
move-corresponding i_eket to it_eket.
append it_eket.
clear it_eket.
endif.
endloop.

CALL FUNCTION 'BAPI_PO_CREATE'
EXPORTING
po_header = i_ekko

PO_HEADER_ADD_DATA =
HEADER_ADD_DATA_RELEVANT =
PO_ADDRESS =
SKIP_ITEMS_WITH_ERROR = 'X'
ITEM_ADD_DATA_RELEVANT =
HEADER_TECH_FIELDS =
IMPORTING
PURCHASEORDER =

tables
po_items = it_ekpo

PO_ITEM_ADD_DATA =

po_item_schedules = it_eket

PO_ITEM_ACCOUNT_ASSIGNMENT =
PO_ITEM_TEXT =

RETURN = return

PO_LIMITS =
PO_CONTRACT_LIMITS =
PO_SERVICES =
PO_SRV_ACCASS_VALUES =
PO_SERVICES_TEXT =
PO_BUSINESS_PARTNER =
EXTENSIONIN =
POADDRDELIVERY =

.
write: po_num.

loop at return.

write:/ return-message,return-type.
endloop.

Here it is.

SAP OOPS ABAP PART 1

SAP OOPS ABAP PART 2

SAP OOPS ABAP PART 3

SAP OOPS ABAP PART 4

SAP OOPS ABAP PART 5

SAP OOPS ABAP PART 6

SAP OOPS ABAP PART 7

SAP OOPS ABAP PART 8

SAP OOPS ABAP PART 9

SAP OOPS ABAP PART 10

SAP OOPS ABAP PART 11

SAP OOPS ABAP PART 12

SAP OOPS ABAP PART 13

SAP OOPS ABAP PART 14

SAP OOPS ABAP PART 15

ABAP TOPIC WISE COMPLETE COURSE

contact

2008-08-11T06:20:00.000-07:00

For advertising contact me at

d_vsuresh@yahoo.co.in

bdc session and call transactions methids

2007-12-21T04:31:00.000-08:00

Data Transfer Methods

You can use the following methods to transfer data:

• CALL TRANSACTION: Data consistency check with the help of screen logic.
• Batch input with batch input sessions: Data consistency check with the help of screen logic

Difference between Batch Input and CALL TRANSACTION

If the direct input cannot be used for your task, this makes creating a data transfer program easier since the underlying transactions ensure that the data consistency checks are executed.

In the case of an error during the data transfer (if data records are inconsistent, for example), you can restart the transfer at the point in the program where the error occurred.
Data Transfer Overview

Batch input methods

With the batch input method, an ABAP program reads the external data that is to be entered in the SAP system and stores the data in a “batch input session”. The session records the actions that are required to transfer data into the system using normal SAP transactions.

When the program has generated the session, you can run the session to execute the SAP transactions in it. You can explicitly start and monitor a session with the batch input management function (by choosing System  Services  Batch input), or have the session run in the background processing system.

CALL TRANSACTION methods

In the second method, your program uses the ABAP statement CALL TRANSACTION USING to run an SAP transaction. External data does not have to be deposited in a session for later processing. Instead, the entire batch input process takes place inline in your program.
Choosing Data Transfer Methods

Selecting a Data Transfer Method

When you transfer data in ABAP, you have three options to submit the data for the data transfer. Only the first two methods can be recommended without reservation. The third method, by way of CALL DIALOG, is outmoded. CALL DIALOG is less comfortable than the other methods. You should use it only if you must.

• Use the CALL TRANSACTION USING statement

Summary:

With CALL TRANSACTION USING, the system processes the data more quickly than with batch input sessions. Unlike batch input sessions, CALL TRANSACTION USING does not automatically support interactive correction or logging functions.
Your program prepares the data and then calls the corresponding transaction that is then processed immediately.

The most important features of CALL TRANSACTION USING are:

o Synchronous processing
o Transfer of data from an individual transaction each time the statement CALL TRANSACTION USING is called
o You can update the database both synchronously and asynchronously
The program specifies the update type
o Separate LUW (logical units of work) for the transaction
The system executes a database commit immediately before and after the CALL TRANSACTION USING statement
o No batch input processing log

• Create a session on the batch input queue.

Summary:

Offers management of sessions, support for playing back and correcting sessions that contain errors, and detailed logging.
Your program prepares the data and stores it in a batch input session. A session is a collection of transaction data for one or more transactions. Batch input sessions are maintained by the system in the batch input queue. You can process batch input sessions in the background processing system.
Your program must open a session in the queue before transferring data to it, and must close it again afterwards. All of these operations are performed by making function module calls from the ABAP program.

The most important aspects of the session interface are:

o Asynchronous processing
o Transfers data for multiple transactions
o Synchronous database update
During processing, no transaction is started until the previous transaction has been written to the database.
o A batch input processing log is generated for each session
o Sessions cannot be generated in parallel
The batch input program must not open a session until it has closed the preceding session.

Executing Data Transfer Programs

Procedure

If you are using an SAP data transfer program, follow the procedure specified in the program documentation.
If you are using a generated data transfer program, proceed as follows:
1. Start the data transfer program.
2. Decide which batch input method you want to use for the data transfer.
a) CALL TRANSACTION USING:

You must specify the:

– Processing mode: You use this parameter to specify whether processing should take place in the background or in dialog mode.
Possible values are:

A Display all
E Display only errors
N No display
– Update mode: This parameter determines how the data is to be updated:
Possible values are:
S Synchronous
A Asynchronous
L Local update

– Error session: Here you have the option to specify a session name for a batch input session in which data is to be written in the case of an error. You can use this to identify incorrect data records after the batch input program has run and to import the records into the R/3 System once you have corrected them.

If you are creating an error session, you must also specify:

– User: Specify the user with whose authorizations the sessions are processed.
– Keep session: This specifies whether or not the session should be deleted once it has been processed.
– Lock date: Specify the processing date for the error session.

b) Generate session:

– Session name: Specify a name for the batch input session to be generated.
– User: Specify the user with whose authorizations the sessions are processed.
– Keep session: This specifies whether or not the session should be deleted once it has been processed.
– Lock date: Specify the processing date for the error session.
3. Specify a character that is to be used as the NODATA character.
4. Specify the path of the data file from which the data is to be imported into the R/3 System.
5. Execute the program.
6. If you have generated a session, or if errors occurred in CALL TRANSACTION USING mode, you must now edit the generated sessions. You can find information on this in BC - System services in batch input sessions.

Creating a Session with BDC_OPEN_GROUP

Use the BDC_OPEN_GROUP function module to create a new session. Once you have created a session, then you can insert batch input data into it with BDC_INSERT.
You cannot re-open a session that already exists and has been closed. If you call BDC_OPEN_GROUP with the name of an existing session, then an additional session with the same name is created.

A batch input program may have only one session open at a time. Before opening a session, make sure that any sessions that the program closes any sessions that it previously had opened.

BDC_OPEN_GROUP takes the following EXPORTING parameters:

• CLIENT

Client in which the session is to be processed.
Default: If you don't provide a value for this parameter, the default is the client under which the batch input program runs when the session is created.

• GROUP

Name of the session that is to be created. May be up to 12 characters long.
Default: None. You must specify a session name.

• HOLDDATE

Lock date. The session is locked and may not be processed until after the date that you specify. Only a system administrator with the LOCK authorization for the authorization object Batch Input Authorizations can unlock and run a session before this date.

Format: YYYYMMDD (8 digits).
Default: No lock date, session can be processed immediately. A lock date is optional.

• KEEP

Retain session after successful processing. Set this option to the value X to have a session kept after it has been successfully processed. A session that is kept remains in the input/output queue until an administrator deletes it.

Sessions that contain errors in transactions are kept even if KEEP is not set.
Default: If not set, then sessions that are successfully processed are deleted. Only the batch input log is kept.

• USER

Authorizations user for background processing. This is the user name that is used for checking authorizations if a session is started in background processing. The user must be authorized for all of the transactions and functions that are to be executed in a session. Otherwise, transactions will be terminated with “no authorization” errors.

The user can be of type dialog or background. Dialog users are normal interactive users in the SAP system. Background users are user master records that are specially defined for providing authorizations for background processing jobs.

Advantages:

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

Session method.

1) synchronous processing.
2) can tranfer large amount of data.
3) processing is slower.
4) error log is created
5) data is not updated until session is processed.

Call transaction.

1) asynchronous processing
2) can transfer small amount of data
3) processing is faster.
4) errors need to be handled explicitly
5) data is updated automatically

RELATED POSTS

SAP ABAP BDC TABLE CONTROL

ABAP TOPIC WISE COMPLETE COURSE

BDC
OOPS ABAP
ALE
IDOC'S
BADI
BAPI
Syntax Check
Interview Questions
ALV Reports with sample code
ABAP complete course
ABAP Dictionary
SAP Scripts
Script Controls
Smart Forms
Work Flow
Work Flow MM
Work Flow SD
Communication Interface
BDC SESSION METHOD SAMPLE CODE
BDC SAMPLE CODE CUSTOMER MASTER
BDC TABLE CONTROL
BDC TABLE CONTROL IN BRIEF
BDC AND LSMW COMARISION
BDC PART 10
BDC PART 9
BDC PART 8
BDC PART 7
BDC PART 6
BDC PART 5
BDC PART 4
BDC PART 3
BDC PART 2
BDC PART 1

ABAP BDC RECORDING

2007-12-05T07:32:00.000-08:00

Recording in BDC means that suppose you want to update some values in MM01 transaction and these values are in a flat file , so first start the recording from transaction sm35 an go new recording, here give the transaction name (e.g.-MM01) , and when the recording ends then go to the programme, it will give you the full recoding code , apply for these code in your original programme and then you will update the new values.

DATA TRANSFER METHODS

You can use the following methods to transfer data:
• Direct input: With direct input, the SAP function modules execute the consistency checks. However with batch input, these consistency checks are executed with the help of the screens. This means that direct input has considerable performance advantages.

• CALL TRANSACTION: Data consistency check with the help of screen logic.
• BATCH INPUT with batch input sessions : Data consistency check with the help of screen logic.

Batch Input

Batch input is a standard technique for transferring large sets of data into the R/3 System. Here the transaction flow is simulated and the data is transferred as if it were entered online. The advantage of this is that all relevant checks of the transaction are executed, thereby ensuring that the data is consistent.
The batch input process is divided into two phases:

1. The data transfer program creates a batch input session that contains all the relevant data.
2. The batch input session is processed and the data it contains is transferred into the R/3 System.

The majority of SAP standard data transfer programs use the batch input technique. The data transfer program creates a batch input session which is processed later. Batch input sessions can be processed in various ways:

• In the foreground
• In the background
• During processing, with error display

You should process BATCH INPUT sessions in the foreground or using the error display if you want to test the data transfer. If you want to execute the data transfer or test its performance, you should process the sessions in the background.

You can find detailed information on batch input in the Basis documentation BC - Basis Programming Interfaces under Transferring Data with Batch Input.

Difference between Batch Input and CALL TRANSACTION

If the direct input cannot be used for your task, this makes creating a data transfer program easier since the underlying transactions ensure that the data consistency checks are executed.

In the case of an error during the data transfer (if data records are inconsistent, for example), you can restart the transfer at the point in the program where the error occurred.

Batch input methods

With the batch input method, an ABAP program reads the external data that is to be entered in the R/3 System and stores the data in a "batch input session". The session records the actions that are required to transfer data into the system using normal SAP transactions.

When the program has generated the session, you can run the session to execute the SAP transactions in it. You can explicitly start and monitor a session with the batch input management function (by choosing System  Services  Batch input), or have the session run in the background processing system.

CALL TRANSACTION methods

In the second method, your program uses the ABAP statement CALL TRANSACTION USING to run an SAP transaction. External data does not have to be deposited in a session for later processing. Instead, the entire batch input process takes place inline in your program.

The information in Choosing Data Transfer Methods will help you decide which is the best data transfer method

The MODE Parameter

You can use the MODE parameter to specify whether data transfer processing should be displayed as it happens. You can choose between three modes:
A Display all. All screens and the data that goes in them appear when you run your program.

N No display. All screens are processed invisibly, regardless of whether there are errors or not. Control returns to your program as soon as transaction processing is finished.

E Display errors only. The transaction goes into display mode as soon as an error in one of the screens is detected. You can then correct the error.
The display modes are the same as those that are available for processing batch input sessions

The UPDATE Parameter

You use the UPDATE parameter to specify how updates produced by a transaction should be processed. You can select between these modes:

A Asynchronous updating. In this mode, the called transaction does not wait for any updates it produces to be completed. It simply passes the updates to the SAP update service. Asynchronous processing therefore usually results in faster execution of your data transfer program.

Asynchronous processing is NOT recommended for processing any larger amount of data. This is because the called transaction receives no completion message from the update module in asynchronous updating. The calling data transfer program, in turn, cannot determine whether a called transaction ended with a successful update of the database or not.

If you use asynchronous updating, then you will need to use the update management facility (Transaction SM12) to check whether updates have been terminated abnormally during session processing. Error analysis and recovery is less convenient than with synchronous updating.

S Synchronous updating. In this mode, the called transaction waits for any updates that it produces to be completed. Execution is slower than with asynchronous updating because called transactions wait for updating to be completed. However, the called transaction is able to return any update error message that occurs to your program. It is much easier for you to analyze and recover from errors.

L Local updating. If you update data locally, the update of the database will not be processed in a separate process, but in the process of the calling program. (See the ABAP keyword documentation on SET UPDATE TASK LOCAL for more information.)

The MESSAGES Parameter

The MESSAGES specification indicates that all system messages issued during a CALL TRANSACTION USING are written into the internal table . The internal table must have the structure BDCMSGCOLL .

This transaction allows a user to record keystrokes and other keyboard actions so that they may be incorporated into a BDC session. While any session may be recorded, it does not mean that the recording can be used to create a session. Within a recording individual screens may not be allowed.

Customized screens may present a problem. Only use the non-customized screens to record sessions.

In this example, the transaction MM is recorded.

Enter transaction SHDB, also called The Transaction Recorder:Recording Overview.

Click on the "New Recording button"

To start a new recording, enter a recording name (up to 10 letters) in the field labeled "Recording," and the Transaction Code MM01. Click either the "Start Recording" button or the green check mark at the bottom of the screen.

Recording the session:

Once the Start Recording button is pressed, the system displays the screens for the transaction code requested. Enter each field needed for the transaction, and proceed to the following screen. A "recording running" message may appear between screens. During a recorded session screen interaction time is extended.

Completing the transaction

End the transaction normally. When completed, the Transaction Recorder: Edit Recording screen is shown, Click the Save icon, which saves the recording. Green arrow back to the starting point (Transaction Recorder).

RELATED POSTS

LEARNING BAPI HERE IS SYSTEMATIC AND DAY WISE.

SAP ABAP BAPI 1
SAP ABAP BAPI 2
SAP ABAP BAPI 3
SAP ABAP BAPI 4

RELATED POST

ALE IDOC'S COMPLETE SERIES

ABAP TOPIC WISE COMPLETE COURSE

ABAP BDC OK CODE

2007-12-02T23:40:00.000-08:00

In your ABAP programs, you should work with the OK_CODE field instead of SY-UCOMM. There are two reasons for this:

Firstly, the ABAP program has full control over fields declared within it, and secondly, you should never change the value of an ABAP system field. However, you should also always initialize the OK_CODE field in an ABAP program for the following reason:

In the same way that the OK_CODE field in the ABAP program and the system field SY-UCOMM receive the contents of the corresponding screen fields in the PAI event, their contents are also assigned to the OK_CODE screen field and system field SYST-UCOMM in the PBO event.

Therefore, you must clear the OK_CODE field in the ABAP program to ensure that the function code of a screen is not already filled in the PBO event with an unwanted value. This is particularly important when the next PAI event can be triggered with an empty function code (for example, using ENTER). Empty function codes do not affect SY-UCOMM or the OK_CODE field, and consequently, the old field contents are transported.

In your application programs, the first step in PAI processing should be to save the function code in an auxiliary variable and then initialize the OK_CODE field. You can then read the function code from the auxiliary variable (for example, using a CASE structure), and control the program flow from there.

The OK_CODE field can have a different name on each screen. However, common practice is to use the same name for the field on each screen of an ABAP program. You then only need one field in the ABAP program, with the same name, into which the function code is placed, and from which you can read it.

RELATED POSTS
shown here.

IMPORTANCE OF BADI IN SAP ABAP

COMPARISON OF ENHANCEMENTS IN ABAP

BADI DEFINITION WITH SCREEN SHOTS

BADI IMPELEMTATION

BADI IMPLEMENTATION PART TWO

MENU ENHANCEMENTS USING SAP BADI

SCREEN ENHANCEMENTS USING SAP BADI

IMPLEMENTATION OF SCREEN ENHANCEMENTS USING BADI

BADI IMPLEMENTATION WITH FORMULA BAR

FILTER DEPENDENT BADI IMPLEMENTATION PART ONE

FILTER DEPENDENT BADI IMPLEMENTATION PART TWO

SAP ABAP FILTER DEPENDENT BADI IMPLEMENTATION

BADI AND OTHER ENHANCEMENTS COMPARISON

SAP ABAP BADI PART ONE

ABAP BADI PART TWO

ABAP BADI PART THREE

ABAP BADI PART FOUR

BADI PART FIVE

ABAP BADI PART SIX CALLING BADI AND ITS USES

BADI INTRODUCTION

RELATED POST

BAPI IN SAP ABAP COMPLETE COURSE

ABAP TOPIC WISE COMPLETE COURSE