SAP ABAP Programming

WORK FLOW SCENARIOS IN SD SAP II

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:53:00 +0530

Processing Credit Memo Requests

Each employee in the sales department is allowed to release credit memo requests up to a value of USD 300. The following authorization procedure has been defined for credit memo requests that exceed this limit:

Credit memo requests with a value of between USD 300 and USD 5,000 may only be
released by the group leader.

Credit memo requests that exceed a value of USD 5,000, may only be released by the
sales manager.

Object Types (SD-SLS-RE)

The interface between R/3 functionality and the workflow system is created using object technology.

In the following scenario, the business application object for
Credit memo requests is Object type BUS 2094.

Initial Values (SD-SLS-RE)

In the workflow, the person who releases or processes the credit memo request is decided according to the value of the credit memo request. You can determine two limit values: Amount limit 1 and amount limit 2.
In order to ensure correct, cross-company code credit memo processing, you also need to specify a reference currency. The document currency for the credit memo request is then converted into the reference currency.

The following company codes and their house currencies exist in one company:

Company code 1: House currency FRF
Company code 2: House currency DEM

The employees assigned to the sales organization process the credit memo requests
for company code 1 and company code 2.
A reference currency (for example, USD) is defined in the workflow container. The
net values in the sales documents are converted into the reference currency which
means that the credit memo requests can then be processed and checked,
independently of the currency in the company code.

Workflow Template (SD-SLS-RE)

Definition

The following two workflow templates are delivered in the standard system for credit memo processing:

Identification:WS20000009
Identification code: Credit memos
Long text: Credit memo processing

Identification: WS20000019
Identification code:CMR_CHECK
Long text: Check credit memo requests
For additional information, see:
Flow of Workflow Template [Page 14].

Use

Workflow Template 20000009 Credit Memo Processing

Triggering Event in Workflow Template

Updating the credit memo request triggers the event created for object type BUS2094 which starts the workflow template.

Workflow Container and Data Flow

The information needed for the workflow is contained in the credit memo request. This
information is available as an event parameter in the container for the triggered event and have to be transferred into the workflow container using data flow.
The following data flow definition between the triggering event and the workflow container is therefore defined in the standard system:
Workflow Container Event Parameter Container

WF_Initiator <-- _EVT_Object (credit memo request)
RefCurrency (reference currency)
CUSTCOMPLAINTORDER
(credit memo request)
NetValue_Limit_1
(amount limit 1)
NetValue_Limit_2
(amount limit 2)
End_Flag
(End indicator)
The _WF_Initiator element is available in the workflow container in the standard system, while the other elements listed here have been added to the workflow container.

Terminating Events

The workflow template for credit memo requests is terminated with the Release credit memo request and Reject credit memo request events.
Check Workflow Template 20000019 Credit Memo Processing

Workflow Container

The workflow container contains the end indicator (End_Flag), information about the credit memo request (CUSTCOMPLAINTORDER) and the employee responsible (ResponsibleAgents).

Processor Assignment

All people or organizational units that are assigned to the workflow template are informed.

Maintain Processor Assignment

Depending on the net value of the credit memo request and the defined organizational plan, the employee responsible receives a workitem in his or hers integrated inbox.
For this to take place, you must list the various objects from organization management in Customizing for the SAP Business Workflow who can work with workflow-relevant credit memo requests, for example, jobs or positions. Before you do that, you need to set up the organizational plan.

User Haywood has the group leader position while user Miller is in the sales
manager position.
Flow for Workflow Template

When you create a credit memo request, the created event is triggered for object BUS2094 and the workflow template 20000009 is started.
The system checks how high the net value of the credit memo request is. If the net value is below limit 1 (minimum limit), the system automatically releases the credit memo request in background processing.

If the net value of the credit memo request is over limit value 1, the system
terminates workflow

template 20000009 and initiates workflow template 20000019.

The relevant employee, depending on the value of the credit memo request and the
organizational structure in use (sales organization, distribution channel, division), is then informed of this by the arrival of a work item in their integrated inbox. If the employee releases the credit memo request, the system ends the workflow and deletes the work item from the inbox.

If the employee stops processing the work item, it remains in the inbox until it has been completed and only then is the workflow finished.

If the employee changes any of the determining factors in the credit memo request (such as net value), the net value of the credit memo request has to be re-checked. The system deletes the work item from the inbox.

Workflow template 20000009 receives a terminating event and workflow template 20000019 is triggered. Depending on the value of the item, the relevant employee is informed and receives a work item in their integrated inbox. Once the employee has finished processing the work item (by rejecting or releasing the credit memo request), the workflow is concluded. If the credit memo request is changed, workflow template 20000019 is called up. Processing continues until the credit memo request has either been rejected or released.

Terminating Events

The workflow template for checking credit memo requests is terminated with the Release credit memo request and Reject credit memo request events.

Standard Tasks (SD-SLS-RE)

Definition

Standard tasks are single-step tasks supplied by SAP that describe basic business activities.

RELATED POSTS

WORK FLOW SCENARIOS IN SD SAP I

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:52:00 +0530

Processing Credit Memo Requests (SD-SLS-RE)

Purpose

Credit memo requests normally need to be checked by the employee who entered them as well as approved by an additional decision-maker. The value of the credit memo determines who is able to approve it.

Once a credit memo request is created, the system normally creates a billing block. This block prevents you from billing the credit memo request and can only be removed by an authorized employee.

Using the workflow, you can represent the whole business process, with all the people involved, for approving credit memo requests within your company. This enables you to process credit memo requests simply and efficiently. If you do not use the workflow, the system does not control the process flow so you will have to organize the steps in credit memo processing yourself.

If the value of a credit memo request is below a minimum value, the system
automatically releases it for billing by removing the billing block.
If the credit memo request exceeds a certain value, the system automatically informs the employee responsible. She or he receives a work item in their inbox and can process it directly from there.
The employee responsible can cancel, release, or process a credit memo request.
If the employee cancels the request, the system automatically creates a reason for rejection in the credit memo request and ends processing.
If the employee releases the request, the system automatically removes the billing block in the
credit memo request and releases it for billing.
If the employee processes the request, she or he can use all the functions available in the change transaction.
The people informed by the workflow do not need to know either the name of the transaction or the menu path of the transactions involved.

Prerequisites

You have configured the settings in Customizing for the workflow and created an
organizational plan (see Preparation and Customizing (SD-SLS-RE) [Page 17]).

When you create credit memo requests, the system normally sets a billing block, which prevents it from being billed. Only authorized employees may remove this billing block, thus releasing the document for billing. The person who is able to check the credit memo before releasing it depends on the value of the credit memo.
You create the billing block for credit memo requests in Customizing for Sales and
Distribution when you define the order type (Sales and Distribution __Sales __Sales
Documents_ Sales Document Header _ Define sales document types).

When using the workflow for processing credit memo requests, we recommend that you
should only allow the billing block to be removed by the people who are authorized to
release credit memos of any value.

Process Flow

Depending on the value of the credit memo request, the system runs through one of the following processes when you enter a credit memo request:

If the value of the credit memo request is smaller or equal to a certain limit (L1), the system automatically releases the credit memo request. The system removes the
billing block in the background, releasing the credit memo request for billing.
If the value of the credit memo request is between limit L1 and limit L2, or equal to L2, the job responsible is informed that the credit memo request should be checked. All the people assigned to this job receive a work item in their integrated inbox, where they can cancel, release or process the credit memo request.

Cancel credit memo request

The employee has to enter a reason for rejection. The system automatically transfers
the reason for rejection into the credit memo request and stops processing.

Release credit memo request
The system automatically removes the billing block in the credit memo request and
releases the document for billing.

Process credit memo request

Here, the user branches into the “Change sales order” transaction, where they can
use all the functions in this transaction. According to the user’s authorization, he or she can remove a billing block, enter a reason for rejection, or process individual items (for example, delete or add order items, or change the order quantity).

The system checks whether the billing block was removed manually. If there is a
billing block, the system re-checks the value of credit memo request and informs the
employee responsible. This process is repeated until the credit memo request has
either been rejected or released.

RELATED POSTS

WORK FLOW SAP IV

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:52:00 +0530

Preparations and Customizing

Determining Responsibilities of the Roles

You must assign SAPorganizationjal object type T024D (MRP controller group). Since the organizational plan is always structured according to you requirements, this step is always necessary.

When you create the assignment, you must specify the plant and the MRP controller so that the MRP controller is uniquely identified. You can create several assignments within your organizational plan.

Executing Task-Specific Customizing

1. Perform task-specific Customizing for SAP Business Workflow.
2. Classify the standard task TS20000477 (Display change management), TS30001203
(Determine possible agent and dispatch), TS20000478 (Create text) and TS20000479
(Display text) as general tasks.
3. Assign the standard task TS20000480 (make change) to the agents who could process it.

Activate Event Receiver Linkage

The event ChangeManagementOpened (configuration change with conflict) for object type
BUS2002 (network) is the triggereing event for workflow template 20000265 (Change
management) and as such is entered in the event linkage table The terminating event
ChangeManagementClosed (Change management concluded) is also entered in this table.

You can find the table in Event creation _ Status management. You decide wheteher you want to mainatin system settings, if you want to use system statauses, or customer settings, if you want to use your own status profile. In our case, the entry is in the system settings.

The status object (NPH), object type (BUS2002) and the event are maintained here. If you select an entry and double-click on Status restriction in the left-hand screen area, the relevant status is displayed. The Inactive field informs you whether the event is created when the status is set or when the status is revoked (subsequent status set).

To actually start the workflow template, the linkage between the triggering event and the workflow template, as receiver of the event, has to be activated in Customizing for SAP Business Workflow.

The event linkage of the workflow templates must also be activated. To create your own workflow template or to display an existing template, in the SAP Business Workflow menu choose Definition tools _ Tasks/Task groups and then the required maintenance transaction. On the initial screen enter Workflow template in the Task type field and the name of the workflow template. Choose either , , or to create, change or display respectively.The workflow template screen appears. To activiate the workflow, choose the Triggering events tab page and activate the event by clicking on the icon in the column so that a green light appears.

Further Options If you want to use the workflow tempalte without a dispatcher, you must delete the following steps: Display change management (TS20000477), Determine possible agents and dispatch (TS30001203)as well as the user decision Do you want to create a text ?. You can delete single steps in the workflow editor. Select the node to be deleted. In the context menu choose Delete. If you delete the Do you want to create a text ? node, you also delete the dependent nodes Create text (TS20000478) and Display text (TS20000479) and the connecting operators. A dialog box to
this effect appears, which you have to confirm. Apart from deleting the nodes, you must change the agent assignment for the Make change (TS20000480) single step.

Delete the SelectedObject expression and enter role 20000054 MRP controller group.You now have to change the autoamtically generated dat flow from the workflow container to the role container. Delete the Org_Object_ID and choose, using F4 help, the
attribute MRP controller group under network.
Check the workflow template and then activate it.
Operation and Connection to the Application Functionality Changes to the configuration of a sales order can occur frequently. Depending on the change
profile and the status of the network, the system can set the Manual adjustment necessary status.

If you have made the necessary settings in Customizing, the workflow template is active and is started automatically from the application.

RELATED POSTS

WORK FLOW SAP III

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:51:00 +0530

Technical Realization

Object Types Used
The interface between the R/3 functionality and the workflow system has been implemented using object technology. As a result, this topic contains information of a more technical nature, than is required for a first overview.

Standard tasks

Standard tasks are single-step tasks delivered from SAP, which describe basic business processes from an organizational point of view. A single-step task always refers to an object method ( technical connection to R/3 functionality) and is linked with possible agents, who are assigned to the relevant part of the organization.
Workflow template The actual business process as been implemented as a workflow template. You can find this workflow template in your R/3 system.

Object Network (BUS2002)

Objects are created in runtime and are the specific instances of pre-defined object types that have been given values. Object types are defined, entering the component, in the Business Object Repository and implemented:

An object Network (BUS2002) exist, for which methods, attributes, and events have been defined that are used by the workflow.
Standard Task TS20000477 Display change management (PSDisplayCM)

Use

In this standard task, the system displays change management for networks to the dispatcher.

He/she then decides which agent is responsible for the change comparison.
Referenced object methods: Object type BUS2002 (network), method

ChangeManagementDisplay (display change management)

Assigning agents: This task should be classed as a general task. General tasks do not have to be assigned to an agent, since they can be carried out by everyone. The agent is determined from the context of the workflow.

Standard Task TS30001203 Determine possible agents and dispatch

Use

This standard task determines the possibe agents for a subsequent task in the workflow. The dispatcher selects an agent from a list of possible agents. This agent is then assigned the singlestep task in the workflow.

Referenced object methods: Object type WF_TASK, method

AllAgentsOfTaskGetAndDispatch (Determine possible agents and dispatch)
Assigning agents: This task should be classed as a general task. General tasks do not have to be assigned to an agent, since they can be carried out by everyone. The agent is determined from the context of the workflow.

Standard Task TS20000478 Create Text (PS-CreaText)

Use

In this standard task, the dispatcher creates a text for the agent.
Referenced object methods: Object type STD_TEXT, method Create (create text)
Assigning employees: This task should be classed as a general task. General tasks do not have to be assigned to an agent, since they can be carried out by everyone. The agent is determined from the context of the workflow.

Standard Task TS20000479 Display Text (PS-DispText)

Use

In this standard text the agent sees the text that the dispatcher created.
Referenced object methods: Object type STD_TEXT, method ReplaceAndDisplay (replace
text symbols)

Assigning agents:s This task should be classed as a general task. General tasks do
not have to be assigned to an agent, since they can be carried out by everyone. The agent is determined from the context of the workflow.

Standard Task TS20000480 Make Change (PS-EditCM)

Use

In this standard task when an agent opens the work item, he/she goes directly to
change mangement for networks, to make the necessary change steps.

Referenced object methods: Object type BUS2002 (network), method

ChangeManagementEdit (make change)

This is ansynchronous method, which means that it can only be completed if another,
terminating, event occurs. In this case, this event is the successful execution of a change comparison for the corresponding network. The work item remains until the event occurs. The terminating event ChangeManagementClosed is defined in the task on the corresponding tab page.

Assigning agents: Here you should enter all the possible agents for confirmation
change management, since the dispatcher sees them in a list. You can assign agents in the task basic data.

You can also define the task as a general task and let the dispatcher choose the agent.
Standard role 20000054 MRP Controller Group (MRPContGroup)

Use roles to specify the agents for tasks or the addressees for messages.
Determining all the agents with the relevant attribute is refered to as role resolution. Each role has a role parameter container that contains the values used in role resolution.

Technical Realization

Entering a role is just one of several ways of finding the responsible agents or addressees. It is also possible to find someone via a suitable organization object (position, job, organization unit) or an expression with reference to the workflow container.

Role resolution is facititated by the SAP organization object MRP Controller Group
(MRP_Controller_Group). The key for the MRP controller group is T024D.
SAP organization object types (short: SAP OrgObjectTypes) represent organizational units on the object type level in the Business Object Repository. Organizational units are used to group employees together and to describe these groups. The key of the SAP organizational object type MRP controller group consists of the plant and the MRP controller.

The object type BUS2002 receives a MRPControllerGroup attribute that represents a object type reference to the SAP organizational object type MRP controller group.
The assignment of the SAP organizational object type MRP controller group to an organizational unit or a position results allows the responsible agent group to be determined at runtime. Since the role entry parameter is BUS2002, the role resolution searches the whole organizational plan for departments that are linked with objects of the type MRP controller group.

All employees in such an organizational unit or position receive the work item.
The role determines the agents for the single step Display Change management. The agents found determine the responsible agent.

RELATED POSTS

WORK FLOW SAP II

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:50:00 +0530

Standard tasks

Standard tasks are single-step tasks delivered from SAP, which describe basic business processes from an organizational point of view. A single-step task always refers to an object method ( technical connection to R/3 functionality) and is linked with employees, who are assigned to the relevant part of the organization.

Standard Task TS20000653:

Abbreviation: PurchOrdPS
Description: Change order network
Referenced object methods, characteristics
Object type: BUS2002
Method: DisplayPurchaseOrderChange
Characteristics: synchronous , with dialog

Process Flow

If there are changes in a network that affect ordered materials or services (quantities or dates), the affected materials are sorted according to purchasing group (in the purchase order). The event PurchaseOrderChange is then triggered for object type BUS2002 for each purchasing group.

The event BUS2002.PurchaseOrderChange is the triggering event for the standard task
TS20000653. It has the following parameters:

Parameter Description

PurchasingGroup Purchasing group
TodoList Internal table containing the changed materials and services
The following data flow has been defined between the event PurchaseOrderChange and the task TS20000653:

Task container Event parameter container

Network _Evt_Object
Start date _Evt_Creation_Date
Start time _Evt_Creation_Time
Triggered by _Evt_Creator
Simple todo list TodoList
Purchasing group PurchasingGroup
The standard task uses the role 00900010 (purcahsing group). It determines all users linked with the relevant purchasing group. If no users have been linked the purchasing in SAP Organization Management, all the users linked to the standard task receive a work item.

Preparations and Customizing

As well as the general Customizing that guarantees the smooth performance of the workflow system, it is also necessary to carry out special Customizing for standard task TS20000653.

Maintaining Employee Assignments

Assign standard task TS20000653 to the employees who could need it. To do so, choose in Customizing Project System _ Workflow _ Configure Standard Tasks for Workflow in the Project System or proceed as follows:
1. On the SAP Easy Access menu choose Tools _ Business Workflow _ Development _
Tasks/Task groups _ Display.
2. Choose Tasks/task groups _ Display and enter the standard task TS20000653
3. Assign the standard task TS20000653 to the users in the organizational unit that is to process the task in your company.
Link Purchasers to Organization Management
If you only want the purchaser responsible to receive a work item (instead of all the possible agents of the standard task TS20000613), link the purchaser to SAP Organizational Management. To do so, use the Customizing activity Project System _ Workflow _ Configure Standard Tasks for Workflow in Project System _ Customizing tasks or proceed as follows:

1. On the SAP Easy Access menu choose Tools _ Business Workflow _ Development
Definition tools _SAP org. objects _ Create assignment.
The Assignment to SAP organizational objects initial screen appears.
2. Enter the organizational object.
3. In the Org. object type field enter T024.

Activating the Event Linkage
The PurchaseOrderChange event for the object type BUS2002 is the triggering event for the standard task TS20000653. Before the standard task can be started event linkage must be activated. To do so, choose in Customizing Project System _ Workflow _ Configure Standard Tasks for Workflow in the Project System or proceed as follows:
1. On the SAP Easy Access menu choose Tools _ Business Workflow _ Development
Definition tools _ Tasks/Task groups_ Display.

The Task: Display screen appears.

2. Enter the standard task TS20000653, choose and go to the Triggering events tab page.
3. Activate the event by clicking on the iicon in the column so that a green light appears.
Maintaining Order Type-Dependent Parameters You must define whether the standard task TS20000653 is to be started for each order type (network type)and plant. Use Customizing activity Project System _ Workflow _ Configure
Standard Tasks for Workflow in the Project System _ Network Type Parameters:

Overview.

Operation

When you execute a work item for standard task TS20000653, you see a screen split into two sections:
On the left-hand side is an overview list of the materials or services. There is checkbox for each material/service. You can use these checkboxes to indicate which materials/services you have already processed.

A red light in front of a material or service means that another work item has been created for this material or service after the current work item was created.
By double-clicking on a material or service in the overview list you can display the detailed data on the right-hand screen.

You can edit exsiting purchase orders or create new ones. A new purchase order does not appear immediately in the table of existing purchase orders. The purchase order has to be saved to the database first. After it has been saved you can display the purchase order by:

Choosing Refresh
Double-clicking on the material or service in the overview list.

You can always interrupt processing of a work item by choosing Cancel, Back or Exit. You can then resume work later. Choose Close Workflow to finish the workflow.

Configuration Change Management (PS)

Purpose

A network can be created for a configurable product from the sales order using assembly processing. The characteristic value assignment is passed directly from the configurable material to the network, and the relevant activities, activity elements, components, PRTs, etc. are selected.

If the configuration of the material, which has an assembly order involving a network, is later changed, a change comparison is started for the network. Objects are added to or deleted from the network. The system tries to make this change comparison automatically. If conflicts arise, the network receives the Manual adjustment necessary status and the change steps have to be processed manually.

The changes to the configuration are made in Sales by the responsible employee. However, an employee in project planning makes the changes to the network. To facilitate communication between the two departments and to avoid long processing times, a workflow template has been created to automate this business process.

Process Flow

The triggering event for this workflow is a conflict during a change comparison, which means that that the Manual adjustment necessary status is set. The flow of the workflow template is as follows:

A dispatcher determines which employee in project planning should make the change
comparison. He/she makes this decision after seeing the network. The dispatcher is determined via a role, that evaluates the network data and the structure of the organization. The dispatcher can then create a text that is sent to the chosen employee. The employee sees this text and can then start processing the network immediately. The workflow finishes when the change comparison is concluded successfully.

RELATED POSTS

WORK FLOW SAP I

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:50:00 +0530

Workflow

Purpose

SAP Business Workflow has the technology and tools for automated control and processing of cross-application processes.
You can use workflow within the Project System to automate and integrate the performance of cross-application and cross-department processes within one project.
The Project System uses _ Predefined standard tasks in purchasing, confirmation, and during configuration changes _ Workflow tasks in milestones, which can also be user-defined.

Preparations and Customizing

Use

To use Workflow in the Project System, you must make the following settings in Customizing for Workflow and the Project System:

Maintain your company’s organization structure
Link the predefined standard tasks with the authorized people in your company
Activate existing event receiver links between triggering events and consuming
workflow tasks.

Name a technical person responsible for each standard workflow template.
Determine whether a work item should be created and make the appropriate setting in
Customizing for network type parameters.
Determine whether a work item should be created if there is a deviation in the duration and work, and make the appropriate setting in Customizing for confirmation parameters.

Standard Tasks in the Project System

SAP has predefined the following standard workflow tasks and provided them with the Project System:
Standard Task TS20000653: Purchase Order Change
If you change dates or quantities of material components in a network with externally processed activities, for which a purchase order has already been created, the system automatically creates a work item.

The purchasing agent receives a message in the mail system regarding the changes that need to be made. This person can then make the necessary changes to the purchase order directly from the mail system.

Standard task TS00007944: Enter actual data

You can create a work item for confirmation from the information system. The pool of
confirmations can be sent to various addresses, for example, to a user or a work center.

Standard Task TS00008015: Deviation in the Confirmation is too Large
If the duration or work exceeds the values you defined in the confirmation parameters in Customizing, the system automatically creates a work item: The MRP controller receives a work item by mail and can display the confirmation or network. The MRP controller can also use the mail system to contact the person who made the confirmation.

Standard Task TS00200040: Change Network
SAP has predefined this standard task which you can use as a model for creating your own standard tasks and workflow tasks for the milestones in a network. This standard task calls up the change network transaction. You can use it to define your own standard tasks and workflow tasks.

WS20000265 Configuration Change Management
This workflow template contains the following standard tasks:
TS20000477 Display change management
TS20000478 Create text
TS20000479 Display text
TS20000480 Make change
User-defined Standard Tasks and Workflow Tasks in

Milestones

You can use the milestone function start workflow task in a network to start:

Standard tasks
Tasks
Workflow tasks

depending on the status of the activity to which the milestone is assigned. You can use network and activity data for the task.
The tasks must meet certain conditions. For more information on how to define user-defined standard and workflow tasks, refer to the Implementation Guide for the Project System under Workflow .

Purpose

If, during network processing, either an external material (non-stock item) or an external service (external activity/service activity) has to be procured, a purchase requisition is created. This is procesed by the purchaser, who creates on or more purchase orders. This is noted in the network.
If changes occur in the nezwork with regards to the ordered materials or services (changed quantities or dates), the sytem automatically changes the purchase requisition. However, any purchase orders that have already been created must be changed manually by the responsible purchaser.

Process Flow

You can use the SAP Business Workflow to inform the responsible purchaser, if based on a change in a network

The required quantity or the requirements date of an external material or service changes or
An external material item or external activity is deleted or
An external activity becomes an internal activity or
The external material or service is no longer required, because the network now has the Technically completed status

And one or more purchase orders have been created for the purchase requisition
The purchaser receives a work item, in which all the relevant changes that affect the external materials or services are listed. He/she can view the purchase requisitions and the existing purchase orders that are affected. It is also possible to edit the purchase orders and to create new orders.

Technical Implementation

Object Types

The interface between the R/3 functionality and the workflow system has been
implemented using object technology. As a result, this topic contains information of a more technical nature, which is now required for a first overview.

In this context, the following object types are important:
BUS2002: Network
Position in the object repository: Project System
T024: Purchasing group
Position in the object repository: Materials management _ Sales

RELATED POSTS

BDC SAP X

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:49:00 +0530

(23) BATCH INPUT RECORDING FOR TRANSACTION RUNS:

This section tells you how to use the recording functions of batch input.
For more information, refer to these sections:

a)Recording features
b)Sample program
c)Special recording features

(24) BATCH INPUT AUTHORIZATIONS:

You need no special authorization -- other than the ABAP/4 run time authorization (authorization object S_PROGRAM -- to run a program that creates batch input. Any user can create batch input sessions.

Starting processing for a session once it is in the queue is another matter, however. To start sessions, you need the authorizations described in "Managing Batch Input Sessions" in the System Services guide.

RELATED POSTS

BDC SAP IX

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:49:00 +0530

Error Analysis and Restart Capability

Unlike "classical" batch input processing using sessions, CALL TRANSACTION USING processing does not provide any special handling for incorrect transactions. There is no restart capability for transactions that contain errors or produce update failures.

You can handle incorrect transactions by using update mode S (synchronous updating) and checking the return code from CALL TRANSACTION USING. If the return code is anything other than 0, then you should do the following:

write out or save the message table
use the BDCDATA table that you generated for the CALL TRANSACTION USING to generate a batch input session for the faulty transaction. You can then analyze the faulty transaction and correct the error using the tools provided in the batch input management facility.

20) USING CALL DIALOG WITH BATCH INPUT:

A program that uses CALL DIALOG to submit batch input should perform the following steps:

1. For the screens you want processed, fill all desired fields.
2. Use a CALL DIALOG statement to call the dialog module and to pass it to the BDCDATA table.

The MODE parameter in the CALL statement is explained in Using CALL TRANSACTION USING for Batch Input(19).

Example

CALL DIALOG 'DIALOG1' USING BDCDATA MODE 'E'.

(21) DIRECT INPUT:

To enhance the batch input procedure, the system offers the direct input technique, especially for transferring large amounts of data. In contrast to batch input, this technique does not create sessions, but stores the data directly. It does not process screens.

To enter the data into the corresponding database tables directly, the system calls a number of function modules that execute any necessary checks. In case of errors, the direct input technique provides a restart mechanism. However, to be able to activate the restart mechnism, direct input programs must be executed in the background only.

To maintain and start these programs, use program RBMVSHOW or the transaction BMV0.

Examples for direct input programs are:

Program Application

RFBIBL00 FI
RMDATIND MM
RVAFSS00 SD
RAALTD11 AM
RKEVEXT0 CO-PA
For more information, see the respective program documentation.

22) SAMPLE BATCH INPUT PROGRAM:

The following program demonstrates both the creation of sessions, and the use of CALL TRANSACTION USING.
REPORT RJBDC200 LINE-SIZE 120.
*----------------------------------------------------------------*
* Add a line in a report *
*----------------------------------------------------------------*
PARAMETERS : BDCTYPE TYPE C DEFAULT 'M',
" M = Create batch input session
" T = Call transaction
"---------------------------------------------------*
" Only used for batch input sessions *
"---------------------------------------------------*
GROUP(12) TYPE C DEFAULT 'BDCTEST',
" group name of session
USER(12) TYPE C DEFAULT SY-UNAME,
" user name for starting the
" session in background
KEEP(1) TYPE C,
" ' ' = delete session after processing
" 'X' = keep session after successful
" processing
HOLDDATE LIKE SY-DATUM,
"---------------------------------------------------*
" Only used for call transaction *
"---------------------------------------------------*
DMODE TYPE C DEFAULT 'A'.
" Display mode
" 'A' = display all screens
" 'E' = display only errors
" 'N' = display nothing
*----------------------------------------------------------------*
* Batch input data for a single transaction *
*----------------------------------------------------------------*
DATA: BEGIN OF BDCDATA OCCURS 0.
INCLUDE STRUCTURE BDCDATA.
DATA: END OF BDCDATA.
DATA: BEGIN OF MESSTAB OCCURS 0.
INCLUDE STRUCTURE BDCMSGCOLL.
DATA: END OF MESSTAB.
*----------------------------------------------------------------*
* Generate batch input *
* *
*----------------------------------------------------------------*
CASE BDCTYPE.
WHEN 'M'.
PERFORM CREATE_GROUP.
EXIT.
WHEN 'T'.
PERFORM CALL_TRANSACTION.
EXIT.
ENDCASE.
*----------------------------------------------------------------*
* *
* Create batch input session *
* *
*----------------------------------------------------------------*
FORM CREATE_GROUP.
WRITE: / 'Create group'.
"------------------------------------------------------------*
" Open batch input group *
"------------------------------------------------------------*
CALL FUNCTION 'BDC_OPEN_GROUP'
EXPORTING
CLIENT = SY-MANDT
GROUP = GROUP
USER = USER
KEEP = KEEP
HOLDDATE = HOLDDATE.
WRITE: / 'BDC_OPEN_GROUP rc ='(999), SY-SUBRC.
"------------------------------------------------------------*
" Insert first transaction *
"------------------------------------------------------------*
PERFORM GEN_BDC_DATA.
CALL FUNCTION 'BDC_INSERT'
EXPORTING
TCODE = 'SE38'
TABLES
DYNPROTAB = BDCDATA.
WRITE: / 'BDC_INSERT rc ='(999), SY-SUBRC.
"------------------------------------------------------------*
" Insert second transaction *
"------------------------------------------------------------*
PERFORM GEN_BDC_DATA.
CALL FUNCTION 'BDC_INSERT'
EXPORTING
TCODE = 'SE38'
TABLES
DYNPROTAB = BDCDATA.
WRITE: / 'BDC_INSERT rc ='(999), SY-SUBRC.
"------------------------------------------------------------*
" Close batch input group *
"------------------------------------------------------------*
CALL FUNCTION 'BDC_CLOSE_GROUP'.
WRITE: / 'BDC_CLOSE_GROUP rc ='(999), SY-SUBRC.
ENDFORM. " End CREATE_GROUP
*----------------------------------------------------------------*
* *
* Call Transaction Using *
* *
*----------------------------------------------------------------*
FORM CALL_TRANSACTION.
WRITE: / 'Call Transaction RC ='(999).
PERFORM GEN_BDC_DATA.
CALL TRANSACTION 'SE38' USING BDCDATA MODE DMODE MESSAGES INTO
MESSTAB.
WRITE: SY-SUBRC, SY-MSGTY, SY-MSGID, SY-MSGNO, SY-MSGV1.
WRITE: / ' ', SY-MSGV2.
WRITE: / ' ', SY-MSGV3.
WRITE: / ' ', SY-MSGV4.
ENDFORM. " End CALL_TRANSACTION
*----------------------------------------------------------------*
* *
* Create batch input data for *
* transaction SE38 *
* *
*----------------------------------------------------------------*
FORM GEN_BDC_DATA.
DATA: LINE LIKE BDCDATA-FVAL.
REFRESH BDCDATA.
*------------------------------------------------------------*
* First screen of transaction *
*------------------------------------------------------------*
PERFORM BDC_DYNPRO USING 'SAPMS38M' '0100'.
PERFORM BDC_FIELD USING 'RS38M-PROGRAMM' 'RJBDC999'.
PERFORM BDC_FIELD USING 'bdc_cursor' 'chap'.
PERFORM BDC_FIELD USING 'BDC_OKCODE' '/00'.
*------------------------------------------------------------*
* In editor, go to bottom of report *
*------------------------------------------------------------*
PERFORM BDC_DYNPRO USING 'SAPMSEDT' '2310'.
PERFORM BDC_FIELD USING 'RSTXP-TDCOMMLINE' 'BOT'.
*------------------------------------------------------------*
* Insert line into report *
*----------------------------------------------------- ------*
PERFORM BDC_DYNPRO USING 'SAPMSEDT' '2310'.
PERFORM BDC_FIELD USING 'RSTXP-TDLINECOM(17)' 'I'.
*------------------------------------------------------------*
* Go to bottom of report again *
*------------------------------------------------------------*
PERFORM BDC_DYNPRO USING 'SAPMSEDT' '2310'.
PERFORM BDC_FIELD USING 'RSTXP-TDCOMMLINE' 'BOT'.
*------------------------------------------------------------*
* Modify line in report and save report *
* (Enter f11 in ok-code) *
*------------------------------------------------------------*
PERFORM BDC_DYNPRO USING 'SAPMSEDT' '2310'.
LINE = 'Batchinput'.
LINE+20 = SY-DATUM.
LINE+30 = SY-UZEIT.
PERFORM BDC_FIELD USING 'RSTXP-TDLINE(17)' LINE.
PERFORM BDC_FIELD USING 'BDC_OKCODE' '/11'.
*------------------------------------------------------------*
* Leave the editor (enter f3 in ok-code) *
*------------------------------------------------------------*
PERFORM BDC_DYNPRO USING 'SAPMSEDT' '2310'.
PERFORM BDC_FIELD USING 'BDC_OKCODE' '/3'.
*------------------------------------------------------------*

* Leave transaction se38 (enter f15 in *
* ok-code) *
*------------------------------------------------------------*
PERFORM BDC_DYNPRO USING 'SAPMS38M' '0100'.
PERFORM BDC_FIELD USING 'BDC_OKCODE' '/15'.
ENDFORM. "End GEN_BDC_DATA
*----------------------------------------------------------------*
* *
* In the batch input data, start a new screen *
* *
*----------------------------------------------------------------*
FORM BDC_DYNPRO USING PROGRAM DYNPRO.
CLEAR BDCDATA.
BDCDATA-PROGRAM = PROGRAM.
BDCDATA-DYNPRO = DYNPRO.
BDCDATA-DYNBEGIN = 'X'.
APPEND BDCDATA.
ENDFORM. "End BDC_DYNPRO
*----------------------------------------------------------------*
* *
* In the batch input data, insert a field *
* *
*----------------------------------------------------------------*
FORM BDC_FIELD USING FNAM FVAL.
CLEAR BDCDATA.
BDCDATA-FNAM = FNAM.
BDCDATA-FVAL = FVAL.
APPEND BDCDATA.
ENDFORM.

------------------------------------------------------------------------------------------------

RELATED POSTS

BDC SAP VIII

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:48:00 +0530

(18) PROCESSING BATCH INPUT SESSIONS:

When you create a batch input session, it remains in the batch input queue until it is explicitly started. Session processing can be started in two ways:

An on-line user can start the session using the batch input menu options. (To access the batch input options, choose System-->Services-->Batch Input.)

You can submit the background job RSBDCSUB to start a session in background processing. If several sessions have the same name, RSBDCSUB starts them all.

It's possible to coordinate the generation and execution of a session in the background processing system.

You can, for example, schedule both the batch input program and RSBDCSUB in the background. If you designate the batch input job as the predecessor for RSBDCSUB, then RSBDCSUB will be started automatically when the batch input job successfully completes.

Alternatively, you can schedule both the batch input program and RSBDCSUB as job steps in a single background job. In this case, however, RSBDCSUB is started even if the batch input program should terminate abnormally.

For detailed information about processing batch input sessions, see MANAGING BATCH INPUT SESSIONS(B) in the System Services guide. You'll find this guide in the Basis library, system administration section, on the SAP documentation CD-ROM.

(19) USING CALL TRANSACTION USING FOR BATCH INPUT:

Processing batch input data with CALL TRANSACTION USING is the faster of the two recommended batch input methods. In this method, batch input data is processed inline in your batch input program.

Error recovery, restarting, and management of batch input processing are all more comfortable if you use "classical" batch input processing by way of batch input sessions. CALL TRANSACTION USING is therefore recommended only if batch input sessions do not run fast enough to meet your requirements.

For more information on choosing a batch input method, please see Selecting a Batch-Input Method(11) .

A program that uses CALL TRANSACTION USING to submit batch input should perform the following steps:

1. Prepare a BDCDATA structure for the transaction that you wish to run. The requirements for filling the BDCDATA structure are the same as for "classical" batch input using sessions. For more information, please see Using the Batch Input Data Structure(12).

2. With a CALL TRANSACTION USING statement, call the transaction and pass the BDCDATA structure to it as batch input. For example:

CALL TRANSACTION 'SE38' USING BDCDATA
MODE 'A'
UPDATE 'S'.
MESSAGES INTO MESSTAB.

The Mode Parameter

The MODE parameter lets you specify whether the batch input processing should be displayed to you as it happens. You can choose between three modes:

A Display everything.
All screens and the data that goes in them appear when you run your program. This is the default setting for MODE in CALL TRANSACTION USING.

N Display nothing.
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. (Database updates however, may have taken place or may have not have taken place, depending on the value of the UPDATE parameter.)

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

The UPDATE parameter lets you 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 batch input 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 batch input 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's 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. (Refer to the keyword documentation of 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.

Example

You can have system messages issued by transaction SE38 (bottom of example) collected in table MESSTAB with the following coding:
DATA BEGIN OF BDCDATA OCCURS 100.
INCLUDE STRUCTURE BDCDATA.
DATA END OF BDCDATA.

DATA BEGIN OF MESSTAB OCCURS 10.
INCLUDE STRUCTURE BDCMSGCOLL.
DATA END OF MESSTAB.

DATA REPORT(8).

BDCDATA-PROGRAM = 'SAPMS38M'.
BDCDATA-DYNPRO = '0100'.
BDCDATA-DYNBEGIN = 'X'.
APPEND BDCDATA.
CLEAR BDCDATA.
BDCDATA-FNAM = 'RS38M-PROGRAMM'.
BDCDATA-FVAL = REPORT.
APPEND BDCDATA.
...
CALL TRANSACTION 'SE38' USING BDCDATA MODE 'N'
MESSAGES INTO MESSTAB.

The following figures show the return codes from CALL TRANSACTION USING and the system fields that contain message information from the called transaction. As the return code chart shows, return codes above 1000 are reserved for batch input.

If you use the MESSAGES INTO option, then you do not need to query the system fields shown below; their contents are automatically written into the message table. You can loop over the message table to write out any messages that were entered into it.

RELATED POSTS

BDC SAP VII

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:47:00 +0530

(14) CREATING BATCH INPUT SESSIONS:

One of the two recommended ways to process batch input data is to store the data in a batch input session. This session can then be run in the SAP System to enter the batch input data into the system.

In general, preparing a session is the best and most comfortable way to process batch input data.

However, you may wish to use the alternate method, CALL TRANSACTION USING, if your batch input sessions cannot be run quickly enough. For more information on choosing the best batch input method, see Selecting a Batch-Input Method(11) .

Creating, Filling, and Closing a Batch Input Session

To create a session, program the following procedure using the following BDC_ function modules:

1. Open the batch input session using function module BDC_OPEN_GROUP(15) .
2. For each transaction in the session:

a. Fill the BDCDATA structure with values for all screens and fields that must be processed in the transaction. For more information, please see Using the Batch Input Data Structure(12).
b. Transfer the transaction to the session with BDC_INSERT(16) .

3. Close the batch input session with BDC_CLOSE_GROUP(17).

The following topics describe these function modules. See Sample Batch Input Program(22) for an example of how the function modules are used.

(15) CREATING A SESSION WITH BDC_OPEN_GROUP :

Use the BDC_OPEN_GROUP function module to do the following 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.

(16) ADDING DATA TO A SESSION: BDC_INSERT :

Use the BDC_INSERT function module to add a transaction to a batch input session. You specify the transaction that is to be started in the call to BDC_INSERT. You must provide a BDCDATA structure that contains all of the data required to process the transaction completely.

BDC_INSERT takes the following parameters:

TCODE

The code of the transaction that is to be run.
For help in finding the transaction code of a function, see Analyzing SAP Transactions(4) .
TCODE is an EXPORTING parameter in the function module.

POST_LOCAL

Parameter to update data locally. If POST_LOCAL = 'X', data will be updated locally.(refer to the keyword documentation of SET UPDATE TASK LOCAL for more information)

DYNPROTAB

The BDCDATA structure that contains the data that is to be processed by the transaction.
DYNPROTAB is a tables parameter in the function module.
For information on filling the structure, see Programming Techniques: Entering Data and Executing Functions(13).

(17) CLOSING A SESSION: BDC_CLOSE_GROUP :

Use the BDC_CLOSE_GROUP function module to close a session after you have inserted all of your batch input data into it. Once a session is closed, it can be processed.

BDC_CLOSE_GROUP needs no parameters. It automatically closes the session that is currently open in your program.

You must close a session before you can open another session from the same program.

You cannot re-open a session once it has been closed. A new call to BDC_OPEN_GROUP with the same session name creates a new session with the same name.

RELATED POSTS

BDC SAP VI

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:47:00 +0530

(13) PROGRAMMING TECHNIQUES :

ENTERING DATA AND EXECUTING

FUNCTIONS:

a)Sample Code: Filling the BDCDATA Structure
b)Identifying a Screen
c)Entering a Value in a Field
d)Executing a Function
e)Entering Values in Loop Fields
f)Positioning the Cursor
g)Ending a Transaction

a)Sample Code: Filling the BDCDATA Structure:

The following form routine shows how the BDCDATA structure should be filled. Build the structure line by line using MOVE and APPEND statements. Before building each line, reset the header line of the internal table with the CLEAR statement.

Special techniques, such as placing the cursor, are not shown in this example.

Example:

Assume in this example that the BDCDATA structure has been declared as BDCDAT in the ABAP/4 program:

FORM Fill-BDC-Table
REFRESH BDCDAT

" Start new DYNPRO
CLEAR BDCDAT
MOVE: TO BDCDAT-PROGRAM.
TO BDCDAT-DYNPRO.
'X' TO BDCDAT-DYNBEGIN.
APPEND BDCDAT.

" Enter fields and values for DYNPRO
CLEAR BDCDAT.
MOVE: TO BDCDAT-FNAM.
TO BDCDAT-FVAL.
APPEND BDCDAT.
CLEAR BDCDAT.
MOVE: TO BDCDAT-FNAM.
TO BDCDAT-FVAL.
APPEND BDCDAT.
...
...
" Start next DYNPRO
CLEAR BDCDAT.
MOVE: TO BDCDAT-PROGRAM.
TO BDCDAT-DYNPRO.
'X' TO BDCDAT-DYNBEGIN.
APPEND BDCDAT.
ENDFORM.

b) Identifying a Screen:

The first record for each screen must contain information that identifies the screen: program name, screen name and a start-of-screen indicator. You record this information in the PROGRAM, DYNPRO, and DYNBEGIN fields of the BDCDATA structure.

This sample BDCDATA starts a screen. The record specifies the program and screen identifiers. With BDCDATA-DYNBEGIN, the record shows that batch input data for a new screen is starting:

Example:

BDCDATA-PROGRAM = 'sapms38m'.
BDCDATA-DYNPRO = '0100'.
BDCDATA-DYNBEGIN = 'x'.
APPEND BDCDATA.

c) Entering a Value in a Field:

After the dynpro-start record, you must add a record for each field that is to receive a value. You need fill only the FNAM and FVAL fields.

This sample BDCDATA enters a value into a field. The FNAM field identifies the target field by its table and field names. FVAL specifies the value that is to be entered:

Example:

BDCDATA-FNAM = 'RS38M-FUNC_EDIT'.
BDCDATA-FVAL = 'x'.
APPEND BDCDATA.

d)Executing a Function:

You can execute a function in a transaction by entering the function code or function key number in the command field of an SAP session. You use the FNAM and FVAL fields to enter this information, just as you would for normal screen fields.

The command field is identified by a special name in batch input, BDC_OKCODE. This name is constant and always identifies the command field.

This sample record would execute the save function. It uses the function key assignment of save, which is F11. A function key number must be prefixed with the / (slash) character:

Example:

BDCDATA-FNAM = 'BDC_OKCODE'.
BDCDATA-FVAL = '/11'.

This sample record also executes save, but uses the function code instead of the function key assignment. All functions, whether they are displayed in menus or as buttons, are identified by function codes. A function code must be prefixed with the = character.

Example:

BDCDATA-FNAM = 'BDC_OKCODE'.
BDCDATA-FVAL = '=UPDA'.

e)Entering Values in Loop Fields

Some screen fields need multiple values, one on each line. To provide input to one of these loop fields, you must use an explicit line index :

Example:

BDCDATA-FNAM = 'fieldx(5)'.
BDCDATA-FVAL = 'value'.

The line index (in the example: (5), line 5) indicates in which loop line on the screen values are to appear.

f)Positioning the Cursor:

To position the cursor on a particular field, you must use the special cursor field:

Example:

BDCDATA-FNAM = 'BDC_CURSOR'.
BDCDATA-FVAL = 'fieldx'.

To position the cursor on a loop field, you must use again an index:

Example:

BDCDATA-FNAM = 'BDC_CURSOR'.
BDCDATA-FVAL = 'fieldy(5)'.

g)Ending a Transaction:

You can successfully complete processing of a transaction in batch input in either of two ways:

leave the transaction and return to the SAP main menu.
trigger an update of the database.

Ending a Transaction

Example:

Returning to the SAP main menu: From the text input screen in the ABAP/4 editor, for example, the following BDCDATA records are necessary to leave the transaction:

BDCDATA-PROGRAM = 'SAPMSEDT'. "Leave text input field
BDCDATA-DYNPRO = '2310'.
BDCDATA-DYNBEGIN = 'X'.

BDCDATA-FNAM = 'BDC_OKCODE'.
BDCDATA-FVAL = '/3'. "Back function key

BDCDATA-PROGRAM = 'SAPMS38M'. "Leave ABAP/4 editor
BDCDATA-DYNPRO = '0100'.
BDCDATA-DYNBEGIN = 'X'.

BDCDATA-FNAM = 'BDC_OKCODE'.
BDCDATA-FVAL = '/15'. "Quit function key

RELATED POSTS

BDC SAP V

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:46:00 +0530

(11) SELECTING A BATCH-INPUT METHOD:

When you generate batch input in ABAP/4, you have three options for submitting the data to batch input processing. 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.

Create a session on the batch input queue.

Summary: Standard method. 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/4 program.

The most important aspects of the session interface are:

Asynchronous processing
Transfers data for multiple transactions
Synchronous database update

During processing, no transaction is started until the previous transaction has been written to the database.

A batch input processing log is generated for each session
Sessions cannot be generated in parallel

The batch input program must not open a session until it has closed the preceding session.

Use the CALL TRANSACTION USING statement

Summary:

Offers faster processing of data than batch input sessions. Recommended if you're having problems getting data entered into your SAP System quickly enough. The playback, interactive correction, and logging facilities offered for batch input sessions are not available for CALL TRANSACTION USING.
Your program prepares the data and calls the desired transaction for immediate processing.

The most important aspects of the CALL TRANSACTION USING interface are:

Synchronous processing
Transfers data for a single transaction
Synchronous and asynchronous database updating both possible
The program specifies which kind of updating is desired.
Separate LUW for the transaction
The system performs a database commit immediately before and after the CALL TRANSACTION USING statement.
No batch input processing log is generated

Use the CALL DIALOG statement

Summary:

Not recommended if you can enter data by way of sessions or CALL TRANSACTION USING.
Your program prepares data for a sequence of dialog screens, and calls a dialog module for immediate processing.

The most important aspects of the CALL DIALOG interface are:

Synchronous processing
Transfers data for a sequence of dialog screens
No separate database update for the dialog
A database update occurs only when the calling program executes a commit operation.

Shares LUW with calling program
No batch input processing log is generated

(12) USING THE BATCH INPUT DATA STRUCTURE:

The batch input structure stores the data that is to be entered into SAP System and the actions that are necessary to process the data. You can think of the structure as storing the script that the SAP System is to follow in processing batch input data.

The batch input structure is used by all of the batch input methods. You can use the same structure for all types of batch input, regardless of whether you are creating a session in the batch input queue or using CALL TRANSACTION USING or CALL DIALOG.

The diagram below shows how to declare the structure in your ABAP/4 program and the fields contained in the structure.

BDCDATA Structure

Information structure: A BDCDATA structure can contain the batch input data for only a single run of a transaction. The typical processing loop in a program is therefore as follows:

Create a BDCDATA structure
Write the structure out to a session or process it with CALL TRANSACTION USING; and then

Create a BDCDATA structure for the next transaction that is to be processed.

Within a BDCDATA structure, data is organized by the screens in a transaction. Each screen that is processed in the course of a transaction must be identified with a BDCDATA record. This record uses the Program, Dynpro, and Dynbegin fields of the structure:

The screen identifier record is followed by a separate BDCDATA record for each value that is to be entered into a field. These records use the FNAM and FVAL fields of the BDCDATA structure. Values to be entered in a field can be any of the following:

data that is entered into screen fields
function codes that are entered into the command field. Such function codes execute functions in a transaction, such as Save.
cursor-positioning commands.

The transaction to which a BDCDATA structure refers is identified separately. If your program writes data to a batch input session, then the transaction is specified in the call to the BDC_INSERT function module. This function module writes a BDCDATA structure out to the session. If your program processes data with CALL TRANSACTION USING, then the transaction is specified directly in this statement.

The following table shows what the contents of a BDCDATA structure might look like. This BDCDATA structure would add a line to a report in transaction SE38, the ABAP/4 Editor:

BDCDATA Structure for Adding a Line to a Report (Transaction SE38)

PROGRAM DYNPRO DYNBEGIN FNAM FVAL
----------------- ------------- ----------------- -------------------------- ----------
SAPMS38M 0100 X
RS38M-PROGRAMM
RS38M-FUNC_EDIT X
BDC_OKCODE =CHAP (Change function code)
SAPMSEDT 2310 X
RSTXP-TDLINECOM(1) B-
SAPMSEDT 2310 X
BDC_CURSOR RSTXP- TDLINECOM(1)
RSTXP-TDLINE(1) BDC Test Text
BDC_OKCODE /11 (Save function key)
SAPMSEDT 2310 X
BDC_OKCODE /3 (Back function key)
SAPMS38M 0100 X
BDC_OKCODE /15 (Quit function key)

Fields: The fields in the BDCDATA structure are as follows:

PROGRAM

Name of the program. Length (8). The PROGRAM field is not case-sensitive. Set this field only in the first record for the screen.

DYNPRO

Number of the screen. Length (4). Set this field only in the first record for the screen.

DYNBEGIN

Indicates the first record for the screen. Length (1). Set this field to X only in the first record for the screen. (Reset to ' ' (blank) for all other records.)

FNAM

Name of a field in the screen. Length (35). The FNAM field is not case-sensitive.

FVAL

Value for the field named in FNAM. Length (132). The FVAL field is case-sensitive. Values assigned to this field are always padded on the right if they are less than 132 characters. Values must be in character format.

Finding function codes and program and field names: Please see Analyzing SAP Transactions(4) for more information.

Data formatting requirements: Please see Data Conversions(6) for more information.

RELATED POSTS

BDC SAP IV

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:45:00 +0530

(5) GENERATING AN SAP DATA STRUCTURE:

You can use the ABAP/4 Dictionary to generate data structures for SAP tables in any of the following programming languages:

Cobol
PL/1
C

You can then incorporate these data structures in your data conversion program.

For most of the standard SAP batch input programs, SAP has also provided special data structure identifiers. With such an identifier, you can generate a listing of all of the table fields that are required by the corresponding batch input program. You do not need to find out which tables are required for the batch input program and generate their structures individually. If you are creating your own batch input procedure, you may be able to use the standard field listings as well.

The names of the special data structure identifiers are documented in the SAP Customizing system. For information on finding the relevant documentation, please see Batch Input Concepts(1).

Data Transfer Programs in ABAP/4

If your data transfer program is written in ABAP/4, you can include data structures of tables in your program with the TABLES instruction. The structure is then read directly from the ABAP/4 Dictionary.

In this case, you cannot use the special data structure identifiers provided by the SAP applications. The identifier names are not recognized by the TABLES instruction. Instead, you can find the required table names by checking the transactions that your batch input procedure will be using to enter data. Or you can find the table names in the listings generated by the special identifiers.

The diagram below shows the structures of transfer programs in ABAP/4 and as external programs written in other languages.

Including Table Structures in Transfer Programs: ABAP/4 and Other Languages

Procedure

To generate a data structure, do the following:

1. Choose Tools --> ABAP/4 Workbench and then ABAP/4 Dictionary.
2. In the ABAP/4 Dictionary, select Environment --> Generate table description.

With this function, you can generate the structures of one or a group of SAP tables in programming code. You can then add this code to your data transfer program.

3. Specify the programming language in which the structure should be generated and identify the tables to be included.

If you wish to use a special structure identifier for a standard SAP batch input report,then enter the identifier in the Key in TSRCG field. Example: The identifier AM-ANLA generates the data structure required for data transfers for the asset management application.

4. The system displays the data structure in list form, as in this example in PL/1 from the asset management application (AM-ANLA):

******************************************************************
* MEMBER GENERATED FROM SAP DATA DICTIONARY *
* T A B L E BALTD *
* DATE: 08.12.1995 TIME: 17:47:16 *
* PLEASE DO NOT CHANGE MANUALLY *
******************************************************************
*
01 BALTD.
*
* Client (Old Assets Data Takeover AM)
05 MANDT PIC X(3)
VALUE SPACE.
* Company code
05 BUKRS PIC X(4)
VALUE SPACE.
* Asset class
05 ANLKL PIC X(8)
VALUE SPACE.

Choose System --> List --> Save --> File to download the data structure to your workstation or PC.

6) DATA CONVERSIONS:

Use the field descriptions that you obtained in Analyzing SAP Transactions(4) or Generating an SAP Data Structure(5) to determine the following:

which fields can be taken over directly from your existing data. That is, there is a direct match between an existing data field and the corresponding SAP data field.

for which fields a conversion procedure is necessary for mapping your existing data to the requirements of the SAP System.

CoNverting Data from Old Format to SAP Format

Your program must format batch input values just as an on-line user would when typing them in. In particular:

The data must be character format.
No piece of data may be longer than its target SAP field.
If the data is shorter than the target field, you must left-justify it within the SAP field (pad it with blanks at the right end).

(7) INITIALIZING AN SAP DATA STRUCTURE:

Standard SAP batch input programs require that every field in a data structure contains either:

a value; or
a special NODATA marker, which indicates that the no batch input data is required for the field.

If you are writing your own data transfer program, you should therefore initialize all of the fields in your batch input data structure with the NODATA character. The NODATA character must occupy the first position in the field, as shown in the figure below.

By default, the NODATA character is the forward slash. To initialize a field to NODATA, you must write this character as the first character in the field value.

If a batch input program finds NODATA in a field, then the program allows the field to default to its standard value in the SAP transaction that contains the field.

Setting the NODATA marker: You can freely select another character as the NODATA marker. Define the new character in the batch input program that reads the data in the BGR00-NODATA field:

Data: like bgr00.
-NODATA = ''.

GENERATING A SEQUENTIAL FILE:

If you are transferring data from a non-SAP System, then you will probably need to use a file as the transfer medium for the data. (For data transfer between SAP Systems, you may be able to use RFC or CPI-C to process data directly in the target SAP System.)

The file that you generate should have the following characteristics:

All data should be in character format. This is required by the standard SAP batch input programs.

Data must have the logical structure expected by the batch input program.

For a standard SAP batch input program, this requirement means that you have generated the data structure defined for the batch input program. For more information, see Generating an SAP Data Structure(5).

You'll find sample code for reading from and writing to a sequential file in Sample Program: Data Transfer(9) .

(9) SAMPLE PROGRAM: DATA TRANSFER:

The following ABAP/4 program demonstrates the data transfer process. The program does the following:

reads customer address data from a sequential file
checks the data for unacceptable records
performs conversions on the data
writes the data back out to a sequential file using the format required by the SAP standard batch input program Batch Input Interface for Customers (ABAP/4 program RFBIDE00).

EXAMPLE:

REPORT BITFER.

* SAP structures for batch input processing:
TABLES: BGR00, BKN00, BKNA1.

* Structure of existing data to be transferred:
DATA: BEGIN OF OLDREC,
TELE1(10) TYPE C,
CUSTNR(8) TYPE C,
TITLE(2) TYPE C,
NAME1(30) TYPE C,
END OF OLDREC.

* Auxiliary structure for initializing fields:
DATA: BEGIN OF AUXREC.
INCLUDE STRUCTURE BKNA1.
DATA: END OF AUXREC.

* SAP fields for converted data:
DATA: CUSTNR LIKE BKN00-KUNNR,
NAME1 LIKE BKNA1-NAME1,
TELE1 LIKE BKNA1-TELF1.

* For initializing fields:
DATA: N TYPE I.
FIELD-SYMBOLS .

* File and session names, NODATA character:
PARAMETERS:
OLDFILE(20) DEFAULT '/tmp/oldfile' LOWER CASE,
SAPFILE(20) DEFAULT '/tmp/sapfile' LOWER CASE,
ERRFILE(20) DEFAULT '/tmp/errfile' LOWER CASE,
SESSION(20) DEFAULT 'ADDRDAT' LOWER CASE,
NODATA DEFAULT '/' LOWER CASE.

START-OF-SELECTION.
OPEN DATASET: OLDFILE FOR INPUT IN TEXT MODE,
SAPFILE FOR OUTPUT IN TEXT MODE,
ERRFILE FOR OUTPUT IN TEXT MODE.

* Open batch input session as first SAPFILE entry:
* program:
MOVE: 'O' TO BGR00-STYPE,
SESSION TO BGR00-GROUP,
SY-MANDT TO BGR00-MANDT,
SY-UNAME TO BGR00-USNAM,
NODATA TO BGR00-NODATA.
TRANSFER BGR00 TO SAPFILE.

* Initialize data fields with NODATA:
DO.
ADD 1 TO N.
ASSIGN COMPONENT N OF STRUCTURE AUXREC TO .
IF SY-SUBRC NE 0. EXIT. ENDIF.
MOVE BGR00-NODATA TO .
ENDDO.
MOVE AUXREC TO BKNA1.

* Read and convert existing data:
DO.
" Read data record:
READ DATASET OLDFILE INTO OLDREC.
IF SY-SUBRC NE 0. EXIT. ENDIF.
" Check data and transfer only certain records:
IF OLDREC-CUSTNR(5) NE 'AABBC'
OR OLDREC-CUSTNR(6) EQ 'AABBCD'
OR OLDREC-TELE1 EQ SPACE.
TRANSFER OLDREC TO ERRFILE.
* TEXT-001: 'Data not transferred for customer:'
WRITE: / TEXT-001, OLDREC-CUSTNR.
ELSE.
" Convert the customer number to SAP convention:
IF OLDREC-CUSTNR+5(1) = 'C'.
IF OLDREC-CUSTNR+5(1) = 'D'.
ENDIF.
" Convert abbreviations to full words:
CASE OLDREC-TITLE.
WHEN 'Co'. BKNA1-TITLE = 'Company'.
WHEN 'Corp'. BKNA1-TITLE = 'Corporation'.
WHEN OTHERS. BKNA1-TITLE = NODATA.
ENDCASE.
" Convert records from old format to SAP format:
MOVE: OLDREC-CUSTNR TO CUSTNR,
OLDREC-NAME1 TO NAME1,
OLDREC-TELE1 TO TELE1.
" Fill SAP structures:
MOVE: '1' TO BKNOO-STYPE,
'XD02' TO BKNOO-TCODE,
CUSTNR TO BKNOO-CKUNNR.
MOVE: '2' TO BKNA1-STYPE,
'BKNA1' TO BKNA1-TBNAM,
'TELE1 TO BKNA1-TELF1,
NODATA TO BNKA1-SENDE.
" Transfer data to SAPFILE:
TRANSFER: BKNOO TO SAPFILE,
BKNA1 TO SAPFILE.
* TEXT-02: 'Data was transferred for customer:'
WRITE: / TEXT-002, OLDREC-CUSTNR, BKNOO-CUSTNR.
ENDIF.
ENDDO.
CLOSE DATASET: OLDFILE, SAPFILE, ERRFILE.

(10) WRITING A BATCH INPUT PROGRAM: PROCEDURE IN OVERVIEW:

In general, you can transfer data from an existing system into the SAP System with pre-defined batch input programs, delivered with the SAP System.

In some cases, however, you will need to write your own batch input program. For example, the standard SAP batch input programs in an application may not have foreseen the data transfer requirement you have, or you may wish to customize the standard data transfer procedure.

To write your own batch input program, you'll need to do the following:

1. Analyze the transaction(s) that you will use to process your batch input data.

You may have already done this when you wrote your data transfer program. Please see Writing a Data Transfer Program(3) and Analyzing SAP Transactions(4) for more information.

2. Decide on the batch-input method that you wish to use.

"Classical" batch input -- by way of a batch input session -- is more comfortable. Restart-capability and detailed logging are supported by the batch input management transaction for batch input sessions.

Batch input by way of CALL TRANSACTION USING offers faster processing if you need it to get your batch input done in the time slot that is available for it. CALL TRANSACTION USING offers, however, less support for error recovery and management of batch input.

For detailed information, please see Selecting a Batch-Input Method(11) .

3. Write the batch input program.

Your program will need to do the following:

read data in, often from a sequential file that has been exported from another system or prepared by a data transfer program
if necessary, perform data conversions or error-checking
prepare the data for batch input processing by storing the data in the batch input data structure, BDCDATA.
generate a batch input session for classical batch input, or process the data directly with CALL TRANSACTION USING.

RELATED POSTS

BDC SAP III

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:45:00 +0530

(3) WRITING A DATA TRANSFER PROGRAM:

The data transfer program is responsible for doing the following:

Converting the data that is to be transferred into the SAP System as required by the SAP data structure or transactions that you are using.

The data structure may be generated from the standard SAP data structures (see Generating an SAP Data Structure(5)). This is required if you are working with a standard SAP batch input program. Or, if you are creating your own batch input procedure, you may have developed the data structure yourself by analyzing the SAP transactions with which the data is to be entered.

A conversion may be necessary for data type and length. The data type required by all standard SAP batch input programs is C, character data. You can find the required field lengths either in your analysis of the SAP data entry transactions or in the data structures that you generate in the ABAP/4 Dictionary.

Exporting the data in SAP format to a sequential file. The batch input program in the SAP System reads the data in from this file.

Task Overview

The tasks involved in writing a data transfer program are shown in the diagram and list below.

Writing a Transfer Program

The procedure:

1. Analyze the structure of your existing data and specify the conversions that are required to fill the SAP data structures.
2. Generate the SAP data structure in code form and insert it into your program.

If the program is written in ABAP/4, you need only include the required tables in your program with the TABLES statement.

3. Initialize the SAP data structure.
4. Fill the structure with data, performing any conversions and error-checking that are required.
5. Write the sequential file that is typically required for making the data available to the batch input program in the SAP System.

(4) ANALYZING SAP TRANSACTIONS:

If you are creating your own batch input procedure, then you will need to analyze the SAP transaction(s) with which the batch input data is to be entered into the SAP System.

The purpose of the analysis is to gather the following information:

the transaction code, if you do not already know it
which fields require input
which fields you can allow to default to standard values
the names, types, and lengths of the fields that are used by a transaction
the identifiers of the functions that you will need to call to have the transaction process the batch input data.

Collecting Transaction Data

To analyze a transaction, do the following:

1. Start the transaction by menu or by entering the transaction code in the command field.

You can determine the transaction name by choosing System --> Status.

2. Step through the transaction, entering the data and performing the functions that will be required for processing your batch input data.

3. On each screen, note the program name and screen (dynpro) number.

Display these by choosing System --> Status. The relevant fields are Program (dynpro)and Dynpro number.

If pop-up windows occur during execution, you can get the program name and screen number by pressing F1 on any field or button on the screen. The Technical info pop-up shows not only the field information but also the program and screen.

4. For each field, check box, and radio button on each screen, press F1 (help) and then choose Technical info.

Note the following information:

The field name for batch input, which you'll find in its own box.
The length and data type of the field. You can display this information by double- clicking on the Data element field.

5. Find out the identification code for each function (button or menu) that you must execute to process the batch input data.

Put the cursor on the button or menu entry while holding down the left mouse button. Then press F1. In the pop-up window that follows, choose Technical info and note the code that is shown in the Function field.

You can also run any function that is assigned to a function key by way of the function key number. To display the list of available function keys, click on the right mouse button. Note the key number that is assigned to the functions you want to run.

Getting Screen and Field Information in the Transaction Interface

Using the Screen Painter and Menu Painter to Get Field and Function Info

You can also obtain field and function information from the screen and menu definitions in the ABAP/4 screen painter and menu painter. For example, you can quickly display field information in the screen painter by displaying the screen in the Fullscreen editor and using the Attribs. for 1 field button for each field.

Getting Field Information in the Screen Painter

Similarly, you can get function and menu codes from the CUA definition of a screen in the menu painter.
See the ABAP/4 Development Workbench documentation for more information on using these tools.

RELATED POSTS

BDC SAP II

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:44:00 +0530

B.MANAGING BATCH-INPUT SESSION.

Batch input sessions enter data non-interactively into an R/3 System. Batch input is typically used to transfer data from non-R/3 Systems to R/3 Systems or to transfer data between R/3 Systems.

This section describes how to manage batch input sessions.
To reach the main menu of the batch input system, select System --> Services --> Batch input.

Overview and Concepts

a) Task Overview: Batch Input
b) Batch Input: Concepts

Working with Batch Input Sessions

c) Processing Sessions Automatically
d) Selecting Sessions
e) Running Sessions
f) Correcting a Session
g) Deleting Sessions
h) Locking and Unlocking Sessions
i) Releasing and Restarting an Interrupted Session

Information and Analysis

j) Displaying Queue Management Information
k) Displaying Session Logs
l) Reorganizing the Log File
m) Analyzing Sessions

a) Task Overview: Batch Input.

With the functions of the batch input management system, you can do the following:

Start batch input sessions to enter data into an R/3 System.
For debugging sessions that contain errors, the batch input system offers two modes for running sessions interactively.

Schedule the background program that automatically submits sessions for processing in
the background.

Lock a session until a specified date.
Locking a session prevents it from being run.

Delete batch input sessions.

Release a session for re-execution if it has been aborted by a system failure or
shutdown while being created or executed.

Analyze a batch input session before or after it has run.
The analysis function lets you display data entered in the transactions in a session. You can:

display the screens called by the session with the session data filled in.
display listings of input fields by field name, with the session data for each field.

Display the log produced by a batch input session.

Functionally:

For help in generating sessions, please see the Basis Programming Interfaces manual.

b) Batch Input: Concepts:

Processing Sessions

A batch input session is a set of one or more calls to transactions along with the data to be processed by the transactions. The system normally executes the transactions in a session non-interactively, allowing rapid entry of bulk data into an R/3 System.

A session simulates on-line entry of transactions and data. It calls transactions and enters data using most of the facilities that are available to interactive users.

For example, the data that a session enters into transaction screens is subject to the same consistency checking as in normal interactive operation. Further, batch input sessions are subject to the user-based authorization checking that is performed by the system.

Generating Sessions

To transfer data with batch-input, the system that is sending the data uses a data transfer interface provided by an R/3 application program in the receiving system. The interface program in the application then produces a batch input session.

The interface program in an application is an ABAP/4 program that sets up the transaction calls and data that make up a session. If the batch input session contains data from an external source, the program also reformats the data to meet the requirements of the input fields in which the data is to be entered. Usually, such programs are provided by the R/3 applications. For more information, please see the documentation of the R/3 applications.

Authorizations

When a session is generated, a client and user are associated with it. If the session is run in background-processing mode, the system uses this user for authorization checking as the session runs. This authorization testing applies whether you sent the job for batch execution or the session was started by a background job.

Sessions that you process in one of the interactive modes are run with your authorizations. The interactive modes are described later in this section.

c) Processing Sessions Automatically:

In most systems, sessions are started non-interactively with a background job that periodically checks for and starts any sessions that have not yet been run. Running sessions interactively is usually reserved for testing sessions or correcting sessions.

To start batch input sessions automatically, schedule the ABAP/4 program RSBDCSUB for repeated execution. The program schedules sessions for immediate execution in the background processing system.

With RSBDCSUB, you can use all of the selection criteria offered on the batch input main menu to select sessions to run:

session name
date and time of generation
status: ready to run or held in the queue because of errors

d) Selecting Sessions:

To reach the main menu for managing batch input sessions, select System --> Service -->
Batch input. On the main menu, you can select sessions using any or all of the following criteria:

session name
date on which the session was generated (entered into the session queue)
session status

You can also select from one of two actions:

To display the session queue, select Session --> Overview.
You can start, analyze, or delete sessions in the queue.

To display session log files, select Session --> Logs.

All sessions generate a log when they are run. From the list of session logs, you can take further actions, such as analyzing a session.

The Session Queue

The information in the session queue includes the following:

Date and Time: The date and time when a session was generated (entered in the
session queue).
Locked: If a session is locked, this column shows the date upon which the system
releases the session. A locked session cannot be started.
Created by: The user who generated the session.
Tran. and Screen: The number of transactions and screens, respectively, that remain to be processed in a session.

Auth. user: The user under whose authorizations the session will be run if it is submitted for batch execution.

You can display statistics on the transactions in any session by marking the session and using the Statistics function.

Session Sorting and Status

Sessions in the session queue are sorted by date and time of generation and are grouped in different lists according to their status.

possible statuses are as follows:

not yet processed

The Tran. and Screen fields in the display show how many transactions and screens,
respectively, the session contains.

held in the session queue because of errors in transactions (Errors in sessions)

Transactions that contained errors are aborted; all correct transactions are processed.
The Tran. and Screen fields in the session display show how many incorrect
transactions were found in the session.
You can restart a session and correct the erroneous transactions with one of the interactive execution modes offered by the batch input system. For more information, please see Correcting a Session(f).

processed

For further information on a session that has been successfully run, you can display the log generated by the session. All completed sessions generate a log. You cannot run a completed session a second time.

Only sessions that were generated with the KEEP option are held in the queue after
processing. Other sessions are deleted after they are successfully completed.

in generation

You will usually see this status only if you happen to display the queue while a session is being generated (entered into the session queue).

You can also encounter this status if a system failure has interrupted the generation of a session. If you suspect that a session has been interrupted, please see Releasing and Restarting an Interrupted Session(i) for more information.

in process

You will usually see this status only if you happen to display the queue while a session is being run.

You can also encounter this status if a system failure has interrupted the execution of a session. If you suspect that a session has been interrupted, please see Releasing and Restarting an Interrupted Session(i) for more information.

e) Running Sessions:

Running a batch input session executes the transactions in the session and enters data into an R/3 System.
To start a session, select Session ® Overview from the main batch input screen. Then mark the session(s) that you wish to start and select Session ® Process or ® Process in batch.
You can start any session in the not yet processed list that is not locked. With Process/foreground or mode, you can also re-start transactions that have the status Incorrect. Sessions with the status Processed cannot be run again.

Run Modes

There are three ways to run a session:

Process/foreground: You can interactively correct transactions that contained errors and step through transactions that have not yet been executed.

Display errors only: This mode is like Process/foreground except that transactions that have not yet been run and which do not contain errors are run non-interactively.

If an error occurs, processing stops and the screen upon which the error occurred is displayed.

Process in Batch: Use batch mode to schedule a session for immediate processing in the batch facility.

You receive control of your terminal again as soon as the session has been passed to the batch system.

Note that your session is automatically released for processing in the background processing system. You need not explicitly release the session for processing.
A completed session is handled in one of three ways:

The system deletes a session from the queue when it has been successfully completed. You can check on the outcome of the session by displaying the session log file.
If the KEEP option was set when the session was generated, then the system leaves a session in the queue, even if it was run successfully. The status is changed to Processed.

You cannot run the session a second time. You must manually delete it when you no longer need it.

If a transaction in the session contained an error, the incorrect transaction is aborted. All other transactions are completed. The session remains in the queue and is held in the Errors section of the list. You can correct the session in one of the interactive modes and run it to completion.

A transaction contains an error if it issues a message of type E (error) or type A (abnormal termination). Other messages are ignored and do not affect the execution of a session..
A session also is held in the queue in the Errors list if the session was ended with the /bend OK code. Please see Correcting a Session(f).

For more information on correcting sessions with the display-all or error-display mode, please see Correcting a Session(f).

f) Correcting a Session:

When a session is run in background-processing mode, the system marks transactions that contain errors as incorrect. All other transactions in the session are completed. The session itself is kept in the session queue in the Errors section of the list.
A transaction contains an error if it generates an error message of type E (error) or type A (abnormal termination). Messages of other types are ignored and do not affect the execution of a session.
You can correct and re-execute the incorrect transactions in an "Errors" session. There are two ways to do so:

1. Re-run the session in display-all or error-display mode. These modes offer the following advantages:

The system skips transactions that were successfully completed. Only incorrect transactions or transactions that have not been executed are run.
You can change inputs and add missing screens interactively as incorrect transactions run.

The following topic provides more information on using display-all mode or error-display mode to correct a transaction.

2. As an alternative, you can analyze the session to determine what the error was. With the analysis displays, you can check the screen that contained the error and the values that were entered in it. You can then correct the program that generated the session and regenerate the session.

You must ensure that the new session does not include transactions that were successfully completed. Otherwise, the updates made by the transactions will be performed again.

Using Display-All Mode

When you use display-all mode to re-start a session that contains an incorrect transaction, the system skips to the first screen of the incorrect transaction. Completed transactions are not re-executed.

options when you run a session interactively.

To correct a transaction, you can:

use the ENTER key to step through the screens recorded in the session

As in normal operation, pressing the ENTER key starts a dialog step. As long as you simply press ENTER, the system processes the screens and data recorded in the session.

change or add values in any screen

When you press ENTER, the system processes the data as altered by you.

branch off from the transaction flow recorded in the session

You can use any function that you wish within the transaction that is currently running. You can, for example, branch off to enter data on a screen that was omitted from the session.
To resume executing the session, return to the screen that was expected by the session.
It holds the data for the screen recorded in the session until you have returned to that screen. It then resumes normal execution of the session.

Interrupting a Session

You can interrupt the interactive execution of a session by entering the /bend OK code on any screen. /bend terminates the transaction currently being executed in the session and marks the transaction with the status Incorrect. The session is kept in the queue and is displayed in the Errors in sessions section of the list.
You can use /bend when testing sessions. For example, you may wish to run the first two transactions of a large session in display-all mode to make sure that the session has been generated correctly.

If the transactions are correct, you can then terminate the run with /bend and then submit the session for background execution. The transactions that have already been run will not be run again.

Deleting a Transaction

You can delete a transaction from a session during interactive execution by entering the /bdel OK code. The transaction is removed from the session. The deleted transaction cannot be run even if you restart the session, and you cannot take back the deletion.

The transaction is, however, available for analysis if the session was generated with the KEEP option set. The transaction is marked with the status Deleted in the analysis display. The deletion also is recorded in the log generated by the session.

g) Deleting Sessions:

You can delete any session from the session queue. Deleting a session discards the session. If the session has already been run, you also delete the session log.

Normally, sessions are deleted from the session queue automatically when they are completed. However, if a session was generated with the KEEP option, it is kept in the session queue. You must explicitly delete the session when you no longer need it.

A session is also kept in the queue if it contained an error or was broken off with the /bend OK code. Such a session is deleted when you finish processing it, unless it was generated with the KEEP option.

To delete a session from the session queue, mark the sessions to be deleted and select Edit --> Delete.

h) Locking and Unlocking Sessions:

You can lock sessions in the session queue by marking the sessions and selecting Edit ® Lock.
Locking a session prevents a session from being started until after the date recorded in the lock. For example, a session locked until the eleventh of November can be started only after that date.
You may wish to lock a session for such reasons as

holding a session until a specified date
preventing a session that contains errors from being re-started
preventing a session that requires a special resource, such as printer forms or a specific tape, from being started unintentionally.

You can unlock a session by changing the lock date to the present date or by entering a space as the lock date.

i) Releasing and Restarting an Interrupted Session:

If a system problem occurs while a session is being generated or is being run, the session is terminated abnormally. Typical causes of an abnormal termination might include shutdown of the R/3 System while a session is running or termination of a SAPGUI presentation process while a session is being run interactively.

In the session queue, a session that was terminated while it was being generated remains in the Being generated section of the list. A session that was terminated while it was running remains in the Active list.

You can recognize that a session has terminated abnormally because the status of the session does not change. If, for example, you find a session that was run the previous night still in the Active list, then it is likely that the session was interrupted.

If a session was to run in the background, you can check the status of the session's job in the background processing system. If the session was aborted, then the background job log contains the reason for the abnormal termination.

Before you can restart (or start) a session that terminated abnormally, you must release it. Releasing the aborted session sets its status to Being processed. Reset the status by marking the session or sessions and selecting Edit --> Release.

You can safely restart a session that was interrupted while it was being run. When you restart the session, all transactions that were successfully completed before the problem occurred will be skipped. The transaction that was executing when the problem occurred will be re-executed.

caution

Release an active session only if you are sure that it has been interrupted and is no longer running.. Sessions also have the status Active while they are running.

caution
Restarting after abnormal termination during generation: You can start a session that was interrupted while it was being generated. The session is guaranteed to contain only complete transactions and to be runnable.

However, there is no guarantee that the session contains all of the transactions that were to be included in it. You may therefore wish to delete and regenerate such a session.

j) Displaying Queue Management Information:

Should you ever need to review the internal queue-management information on a particular entry, you can display this information by marking an entry and selecting Analysis --> Queue.
Not all of the queue management fields displayed are used by the batch input system; the queue management functions are used by other queues in the system as well. The fields that are used by the batch input system are as follows:

Client: The client in which a session is to run.
Groupid: The session name.
QID: The internal ID of a session. The ID is used for queue management with System -> Services --> Queue.
QSTATE: A character indicating the status of the batch input session.
QERASE: If marked, indicates that the KEEP option is set. If KEEP is set, the system does not delete the session after it is successfully run.
USERID: User to be used for authorization testing if a session is submitted for background execution.
displaying Session Logs:

Every batch input session generates a log when it runs. To display a log, you can either:

select Session --> Logs from the batch input main menu; or
put the cursor on a particular session in the session queue and select Goto --> Log.

A session log contains any error messages issued by transactions in the session. It also includes batch input error messages reporting any problems in running transactions, together with the transaction and screen at which the problem occurred. Finally, a log contains a set of summary statistics.

l) Reorganizing the Log File:

You should periodically use the ABAP/4 program RSBDCREO to reorganize the batch input log file. You can run RSBDCREO in the background or interactively.

Running the program reduces the size of the log file, BI, in the shared R/3 directory "global" in the host system to the minimum possible size. Deleting a session marks a session log for deletion, but the storage held for the log is returned to the host only by a reorganization.

The program will delete a log only if the session to which the log belongs has been deleted.

m) Analyzing Sessions:

Use the analysis functions to check on the actions performed by a batch input session. The analysis functions allow you to display the transactions, screens, and data in a session.

You can use these functions before or after a session has been run.

note
Analysis of sessions that have been run is available only for sessions that contained an error or which were generated with the KEEP option. The KEEP option prevents the system from deleting a session that has been successfully run.

You can analyze a session by marking the session in the session queue and selecting Goto --> Analysis --> Session or by selecting Analysis from the session log screen.

Analysis Blocks

Reading very long sessions from the database can cause time-outs to occur. For this reason, the system reads sessions for analysis in blocks.

Blocks do not restrict your ability to display a long session. You can switch forward and backward from block to block with function keys.

A block always contains only complete transactions. A block boundary cannot fall in the middle of a transaction.

Session Summary

The first analysis screen lists the transactions and screens recorded in the session.

Screens are identified by the name of the program and the number of the screen. Statuses are identical to those of the session queue, except that transactions that were deleted with the /bdel OK code have the status Deleted.

Session Data

You can display the data entered on each screen of a session by selecting Analysis ® Data from the first analysis screen.

You can have the data presented to you in two formats:

• The first data display presents data in list format by field name.
• Alternatively, you can switch to the screen called by the session with the session data shown on it.

You can switch back and forth from one form of display to the other.

RELATED POSTS

BDC SAP I

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:43:00 +0530

(1) BATCH INPUT CONCEPTS:

The SAP System offers two primary methods for transferring data into the System from other SAP Systems and non-SAP Systems. These two methods are collectively called "batch input" or "batch data communication."

basic technique for data transfer with batch input.

Both batch input methods work by carrying out normal SAP transactions, just as a user would. However, batch-input can execute the transactions automatically and is therefore suitable for entering large amounts of data that are already available in electronic form.
The batch input technique offers these advantages for transferring data:

No manual interaction is required during data transfer. If the data to be transferred is already available in electronic form (on a tape, for example), then you can enter the data automatically into the SAP System using batch input.

Batch input ensures data integrity. Batch input enters data into the SAP System using the same transactions that interactive users do. Batch input data is therefore submitted to all of the checks and controls that apply to data entered by normal interactive means.

The batch input methods.

There are several ways to process batch input data in the SAP System.

Batch input processing methods.

The first processing method could be called "classical batch input." In it, an ABAP/4 program reads the external data that is to be entered in the SAP System and stores the data in a "batch-input session." A session stores the actions that are required to enter your data using normal SAP transactions.

When the program has finished generating the session, you can run the session to execute the SAP transactions in it. You can either explicitly start and monitor a session with the batch-input management function (System --> Services --> Batch input) or have the session run in the background processing system.
This method uses the function modules BDC_OPEN, BDC_INSERT, and BDC_CLOSE to generate sessions.

In the second method, your program uses the ABAP/4 CALL TRANSACTION USING statement to run an SAP transaction. Batch-input 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.

There is a third batch-input method using the ABAP/4 CALL DIALOG statement. However, SAP recommends against using this method unless necessary. The CALL DIALOG method is now outdated and is more complex and less comfortable to use than the other techniques.
All three batch-input methods use a common data structure for holding the instructions and data for SAP transactions. This structure is defined as structure BDCDATA in the ABAP/4 Dictionary.

For help in selecting the method to use, please see SELECTING A BATCH-INPUT METHOS (11).

Typical uses of batch input.

Uses of batch input include the following:

transferring data from another system when you install your SAP System
regularly transferring data that is captured by a non-SAP system in your company into the SAP System. Assume, for example, that data collection in some areas of your company is still performed by a non-SAP system. You can still consolidate all of your data in the SAP System by exporting the data from the other system and reading it into the SAP System with batch input.

You can also use batch input to transfer data between two R/3 Systems. However, there are more direct methods for doing this, such as RFC (remote function calls).

application support for batch-input.

The SAP applications provide pre-programmed support for batch input transfers for many of SAP's business objects.
To implement one of the supported data transfers, you must often write the program that exports the data from your non-SAP System. This program, known as a "data transfer" program must map the data from the external system into the data structure required by the SAP batch input program.
Should you wish to write a transfer program that executes outside the SAP System, then the SAP applications provide definitions of the required data formats for the exports. From these definitions, you can generate code for the data structures to include in your export program. You can also write such programs in ABAP/4, which lets you take advantage of the comfort and conveniences of the SAP Development Workbench.
Once you have exported the data, you can then use a standard, pre-programmed SAP report to import the data. This program uses one of the batch input methods to process the data and add it to the SAP System.

You can find information on pre-defined batch-input programs in the SAP Customizing System. Choose Tools --> Customizing. Then display either your Enterprise IMG (Implementation Guide) projects or the SAP standard IMG. In the project display, use the Expand function to display all nodes in the project. You can then search for relevant topics with the keywords batch input and transfer.

(2) TRANSFERING DATA : BATCH INPUT PROCEDURE IN OVERVIEW.

Transferring data with batch input requires the steps shown in the illustration and list below.
Note that SAP standard batch-input programs take care of several of these steps for you. For more information, please see BATCH INPUT CONCEPTS (1).

The procedure:

1. Analyze the data that is to be transferred to the SAP System.

Goal: Determine how your existing data should be mapped to the SAP data structure.
Method: You'll need to determine the structure of the data that is to be transferred into the system. Using the SAP data structure that you generate in step 2, you'll need to determine how the data to be transferred must be mapped to the SAP structure. You'll also need to determine whether any data type or data length conversions are required.

For more information, please see DATA CONVERSIONS(6).

2. Generate SAP data structures for incorporation into your data export program.

Method: Use the data structure generation function of the ABAP/4 dictionary to generate data structures for SAP tables in any of several programming languages.
If you are using one of SAP's standard batch input programs, then use of this function is required. The standard batch input programs generally require that you use a special pre-defined data structure.

For more information, please see GENERATING AN SAP DATA STRUCTURE(5).

If you're writing your own batch input procedure, then you will need to determine the data structure on your own. You'll need to analyze the SAP transactions to find the names of the fields that the transaction requires. For more information, please see ANALYSING SAP TRANSACTIONS(4).

3. Code your data transfer program. You can write the program in ABAP/4 or as an external program. You'll find more information in WRITING A DATA TRANSFER PROGRAM(3).

4. Export the data that is to be transferred to a sequential file.

Requirements:

The file must use the logical format required by the batch-input program that will import the file (step 6).

Reading and interpreting the file is much easier if you write it in ASCII or EBCDIC
(character) format rather than, for example, writing numeric data in hexadecimal format.

Character format is required by the pre-defined SAP batch input programs.

5. If necessary, code the ABAP/4 batch input program that will read in the data to be transferred from your file.

SAP supplies ready-to-run batch-input programs for most of the SAP applications.

For more information on writing your own program, see WRITING A BATCH INPUT PROGRAM : PROCEDURE IN OVERVIEW(10).

6. Process the data and add it to the SAP System. You can do this either by:

GENERATING A BATCH-INPUT SESSION(A) ; or
by processing data directly in your batch-input program with the ABAP/4 statement
CALL TRANSACTION USING (19).

7. Check that all data has been successfully processed.

Method: Analyze the batch input processing log. If you are using CALL TRANSACTION USING, then you will need to analyze the processing messages collected by your program.
You'll find more information on running and analyzing sessions and logs in MANAGING BATCH-INPUT SESSIONS(B).

8. Correct and re-process erroneous data.

Method: You can use the batch-input management function to process erroneous transactions interactively. You can correct data during this interactive processing.

A.GENERATING A BATCH-INPUT SESSION.

One of the two recommended ways to process batch input data is to store the data in a batch input session. This session can then be run in the SAP System to enter the batch input data into the system.

In general, preparing a session is the best and most comfortable way to process batch input data. However, you may wish to use the alternate method, CALL TRANSACTION USING, if your batch input sessions cannot be run quickly enough. For more information on choosing the best batch input method, see SELECTING A BATCH-INPUT METHOD(11).

Creating, Filling, and Closing a Batch Input Session

To create a session, program the following procedure using the following BDC_ function modules:

1. Open the batch input session using function module BDC_OPEN_GROUP (15) .
2. For each transaction in the session:

a. Fill the BDCDATA structure with values for all screens and fields that must be
processed in the transaction. For more information, please see USING THE
BATCH-INPUT DATA STRUCTURE (12).

b. Transfer the transaction to the session with BDC_INSERT (16) .

3. Close the batch input session with BDC_CLOSE_GROUP (17).

The following topics describe these function modules. See SAMPLE BATCH INPUT PROGRAM(22) for an example of how the function modules are used.

RELATED POSTS

BADI SAP III

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:42:00 +0530

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 use, 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 consits 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 are 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

BADI SAP II

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:42:00 +0530

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.

This graphic shows the process flow of a program that contains a business add-in call. It enables us to see the possibilities and limitations inherent in business add-ins.

Not displayed: You must declare a reference variable in the declaration part.
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.

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.

You can also use search tools: Since SAP provided fewer than 50 Business Add-Ins in Release 4.6A, even a list of them all is still manageable.

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.

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).

RELATED POSTS

BADI SAP I

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:41:00 +0530

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 are 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 runtime instances that are based on the same template. Instead of loading a single runtime instance of a function group implicitly when you call a function module, ABAP programs can create runtime instances of classes explicitly. The individual runtime 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, take 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 reimplemented by other links in the software chain (as shown on the right in the graphic).

Furthermore, an implementation can also offer business add-ins of its own.

RELATED POSTS

BAPI SAP IV

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:41:00 +0530

Programming Methods for Sub-Objects

Use

If a business object type consists of sub-objects, you can implement the following standardized BAPIs to add or remove sub-objects:

Add

This method adds a sub-object to an object type.

Remove

This method removes a sub-object from an object.

For example, to add or remove the sub-object purchase order item to the business object type purchase order, the BAPIs AddItem() and RemoveItem() could be implemented for the object type, purchase order.

The BAPIs Add and Remove are instance methods.

Features

Import Parameters

Both BAPIs' import parameters must contain in the function module the data that uniquely identifies the sub-object as well as the key fields of the business object.
If required, you can create also create these parameters:

A test run parameter for checking the entry for an object instance before actually creating the instance in the database.

A change parameter to identify parameter fields containing modified values and parameter fields that have not been modified.
For more information about these parameters see Standardized Parameters.
Export Parameters

You should only create the export parameter RETURN in the BAPI Remove to return messages from the method call to the calling program. For more information about this parameter see Return Parameters (Error Handling).
To make the object key available to the calling program, the key fields of the object type must also be returned in the export parameters of the BAPI Add as well as in the export parameter Return.

Extension parameters

You can create extension parameters to enable customers to enhance the functionality of BAPIs without making modifications. For information about extension parameters see Customer Enhancement Concept for BAPIs.

Locking

We recommend that you implement methods of sub-objects without the locking function and create your own BAPIs instead that lock the relevant data.

If you are implementing BAPIs that create or change data you should consider using buffering. For further information see Buffering for Write BAPIs.
BAPIs for Mass Processing

The BAPIs listed in the above section, "BAPIs for Creating or Changing Data", can also be used for mass processing. Here, when a BAPI is called, several business object instances are processed at the same time.

With BAPIs for mass processing, the suffix "Multiple" is added to the method name, for example, ChangeMultiple(), CreateMultiple(), DeleteMultiple(). The BAPIs here are always class methods.

We strongly recommend that you create instance-dependent BAPIs with buffering instead of Multiple() BAPIs. For further information see Buffering with Write BAPIs.
BAPIs for Replicating Business Object Instances
The following BAPIs are used for replicating business object instances:
Replicate() and SaveReplica()
The BAPIs Replicate() and SaveReplica() are implemented as methods of replicable business object types(). They enable specific instances of an object type to be copied to one or more different systems. These BAPIs are used mainly to transfer data between distributed systems within the context of Application Link Enabling (ALE). These BAPIs are class methods.

Buffering with Write BAPIs

Use

To save external systems each having to define their own data, predefined buffering mechanisms should be implemented in all write BAPIs (i.e. BAPIs that create and change data).

For SAP internal use this is particularly relevant for BAPIs developed as of Release 4.6A. If you want to implement a buffer for BAPIs in an earlier release, you should first contact a colleague in the central BAPI development group.

For BAPIs standard R/3 System mechanisms can be used to buffer application data. Data to be created or changed by a BAPI is not created in the update buffer, it is first collected in the global buffer of the BAPI function module group. Then the whole buffer is updated at a specified time.

This has the following advantages:

Improvement in performance of the whole system.
The updating of individual operations is delayed and they can all be updated together. Techniques such as "array insert" improve system performance. If buffering is not used, each change must be updated separately.

Several changes to an application instance
With the first change the data is read from the database into the buffer and the change is made in the buffer. With the next change, the system recognizes that the data already exists in the buffer and also makes the change in the buffer. If buffering were not used, the first change would have to be updated before a second change could be made.

Using in Application Link Enabling
BAPIs with buffering are especially suited in situations where mass data is exchanged between systems via Application Link Enabling (ALE).
The buffering mechanism enables application instances to be processed separately in the ALE layer, while still enabling the instances to be updated together. Unlike multiple BAPIs, such as, SaveReplicaMultiple(), this procedure allows error handling of individual instances.

BAPIs with buffering mean that there is no need to use or implement multiple BAPIs.

Integration

The Transaction Model for BAPIs Without Commit in use since Release 4.0 can be enhanced on the basis of these advantages:

Within one Logical Unit of Work (LUW) several changes or detailed changes can be carried out for one instance.

All changes (to one or more instances) are updated together by the BAPI BapiService.TransactionCommit().

Prerequisites

The buffering mechanism for BAPIs must be implicit, that is, the caller must not have to control the buffering. A calling program must be able to use, for example, a Create()or Change() BAPI with buffering as well as it can use a BAPI without buffering. The buffer is updated implicitly in R/3.

If buffering has been implemented for a business object type, all write BAPIs of this business object type must also be implemented with buffering.
If write BAPIs with buffering have been implemented for a business object type, this affects the read BAPIs of this object type. Refer to the information in the Activities section below.

Features

For BAPIs with buffering, in addition to the standard guidelines, the following implementation steps and characteristics described below are required.

Function Modules for Updating the Contents of the Buffer

As BAPIs with buffering can only create or change instances in the buffer, you have to provide one or more function modules to carry out the final update of the buffer contents. These update modules transfer the entire contents of the buffer to the update program.

These function modules should not be implemented as BAPIs, as these are only used in the system in which the buffer is also used.
The naming convention for these function modules is:
_SAVEBUFFER.

Exceptions must not be defined for the update modules, as these are not run until the end of the program, when error handling is no longer possible.

Function Modules for Deleting the Contents of the Buffer

To ensure that the buffer is empty at the start of a transaction, you must provide a function module that deletes the contents of the buffer. This delete function module deletes the entire contents of the buffer and removes any locks on the instances. Neither should you implement this function module as a BAPI, because it is only used in the system in which the buffer is also used.

The naming convention for this function module is:

_CLEARBUFFER.

No exceptions can be defined for delete modules because these are not run until the end of the transaction, when error handling is no longer possible (see Special Characteristics below).

Special Characteristics

BAPIs with buffering need to have special characteristics. For example, these BAPIs must be able to deal with errors because a caller cannot reprocess data in the buffer. As data is buffered implicitly, no administration BAPIs are provided for callers.

Consistency of the Buffer Contents

A BAPI with buffering must carry out all the processing steps, except for updating. The consistency of all instances created or changed in the buffer must be guaranteed by the application.

This means that:

Only operations that can be updated with consistency guaranteed can be carried out in the buffer. The update module itself cannot perform consistency checks.

All other steps required before updating, such as assigning numbers or creating application blocks, must be carried out before calling the update module.

For operations that cannot be updated consistently, no action can take place. In these cases the error situation must be reported in the BAPI return parameter.
Calling Update Modules

After the buffer operations have been successfully carried out, using the command
PERFORM ON COMMIT
call a form routine which then calls the update module(s).
The update modules must be called using the command
CALL _SAVEBUFFER IN UPDATE TASK
to flag the execution in the update program.

By adding 'ON COMMIT' to the command PERFORM ON COMMIT, updating is not carried out immediately,it is carried out in the next COMMIT WORK. This way any number of BAPI calls can be collected together. The final COMMIT WORK command that is executed via the BAPI BapiService.TransactionCommit(), executes the form routine and also each update module once only. For this reason error handling cannot be performed in this form routine or in the function module.

Subscribing the Delete Module

At the start of each LUW the buffer must be empty. Any instances that may exist in the buffer, which were updated in an earlier LUW, are no longer blocked and may be older than the versions in the database. If this instance is updated again, inconsistencies would result.

At the end of each LUW, the buffer contents must be deleted by calling the delete module. This can only be done by the BAPIs BapiService.TransactionCommit() and BapiService.TransactionRollback(). To supply these BAPIs with the necessary information, BAPIs with buffering must subscribe their delete module for the BAPI BapiService.TransactionCommit() bow. BapiService.TransactionRollback().

The delete module is subscribed by calling the central function module BUFFER_SUBSCRIBE_FOR_REFRESH, whereby the parameter NAME_OF_DELETEFUNC must contain the name of the delete module.

No COMMIT WORK or ROLLBACK WORK Command
BAPIs with buffering must not execute COMMIT WORK or ROLLBACK WORK commands.

Documentation

Each BAPI with buffering must be explicitly documented as such.

Activities

Keep in mind the following important information about how write BAPIs with buffering interact with read BAPIs of the same business object.
Write BAPIs with Buffering and Read BAPIs for the Same Business Object
No Buffering for Read BAPIs

If write BAPIs with buffering are implemented for the same business object type, read BAPIs are not allowed to use the buffer for the same business object type, so that data read from the database can be stored, thereby avoiding further database accesses.

As the imported data is not locked, the corresponding data in the buffer would become outdated over time. Subsequent read operations would first access the buffer and read the potentially out-of-date data, as data in the database can only be read, if this data is not in the buffer.
Buffer Instances Are "Real" Instances

All instances created or changed by write BAPIs in the buffer are consistent. They can be used by other change BAPIs for further processing within the same LUW.
To guarantee the consistent behavior, all read BAPIs must handle existing instances that are in the buffer, and not yet in the database, as valid instances. Read BAPIs must be implemented in such a way that they first try to read an instance in the buffer and only start searching the database, if the instance is not found in the buffer.

A buffer instance is therefore "real" instance. For example, a BAPI ExistenceCheck() must search for the existence of an instance in the buffer also.
Documenting Read BAPIs
Each read BAPI that handles the buffering of corresponding write methods must be documented.

Prerequisites

The buffering mechanism for BAPIs must be implicit, that is, the caller must not have to control the buffering. A calling program must be able to use, for example, a Create()or Change() BAPI with buffering as well as it can use a BAPI without buffering. The buffer is updated implicitly in R/3.
If buffering has been implemented for a business object type, all write BAPIs of this business object type must also be implemented with buffering.

If write BAPIs with buffering have been implemented for a business object type, this affects the read BAPIs of this object type. Refer to the information in the Activities section below.

Features

For BAPIs with buffering, in addition to the standard guidelines, the following implementation steps and characteristics described below are required.
Function Modules for Updating the Contents of the Buffer
As BAPIs with buffering can only create or change instances in the buffer, you have to provide one or more function modules to carry out the final update of the buffer contents. These update modules transfer the entire contents of the buffer to the update program.

These function modules should not be implemented as BAPIs, as these are only used in the system in which the buffer is also used.
The naming convention for these function modules is:
_SAVEBUFFER.

Exceptions must not be defined for the update modules, as these are not run until the end of the program, when error handling is no longer possible (see Special Characteristics below).

Function Modules for Deleting the Contents of the Buffer

To ensure that the buffer is empty at the start of a transaction, you must provide a function module that deletes the contents of the buffer. This delete function module deletes the entire contents of the buffer and removes any locks on the instances. Neither should you implement this function module as a BAPI, because it is only used in the system in which the buffer is also used.

The naming convention for this function module is:

_CLEARBUFFER.
No exceptions can be defined for delete modules because these are not run until the end of the transaction, when error handling is no longer possible (see Special Characteristics below).

Special Characteristics

BAPIs with buffering need to have special characteristics. For example, these BAPIs must be able to deal with errors because a caller cannot reprocess data in the buffer. As data is buffered implicitly, no administration BAPIs are provided for callers.

Consistency of the Buffer Contents

A BAPI with buffering must carry out all the processing steps, except for updating. The consistency of all instances created or changed in the buffer must be guaranteed by the application.

This means that:
• Only operations that can be updated with consistency guaranteed can be carried out in the buffer. The update module itself cannot perform consistency checks.
• All other steps required before updating, such as assigning numbers or creating application blocks, must be carried out before calling the update module.
• For operations that cannot be updated consistently, no action can take place. In these cases the error situation must be reported in the BAPI return parameter.
Calling Update Modules

After the buffer operations have been successfully carried out, using the command
PERFORM ON COMMIT
call a form routine which then calls the update module(s).
The update modules must be called using the command
CALL _SAVEBUFFER IN UPDATE TASK
to flag the execution in the update program.

By adding 'ON COMMIT' to the command PERFORM ON COMMIT, updating is not carried out immediately,it is carried out in the next COMMIT WORK. This way any number of BAPI calls can be collected together. The final COMMIT WORK command that is executed via the BAPI BapiService.TransactionCommit(), executes the form routine and also each update module once only. For this reason error handling cannot be performed in this form routine or in the function module.
Subscribing the Delete Module
At the start of each LUW the buffer must be empty. Any instances that may exist in the buffer, which were updated in an earlier LUW, are no longer blocked and may be older than the versions in the database. If this instance is updated again, inconsistencies would result.

At the end of each LUW, the buffer contents must be deleted by calling the delete module. This can only be done by the BAPIs BapiService.TransactionCommit() and BapiService.TransactionRollback(). To supply these BAPIs with the necessary information, BAPIs with buffering must subscribe their delete module for the BAPI BapiService.TransactionCommit() bzw. BapiService.TransactionRollback().
The delete module is subscribed by calling the central function module BUFFER_SUBSCRIBE_FOR_REFRESH, whereby the parameter NAME_OF_DELETEFUNC must contain the name of the delete module.
No COMMIT WORK or ROLLBACK WORK Command

BAPIs with buffering must not execute COMMIT WORK or ROLLBACK WORK commands.

Documentation

Each BAPI with buffering must be explicitly documented as such.

Activities

Keep in mind the following important information about how write BAPIs with buffering interact with read BAPIs of the same business object.
Write BAPIs with Buffering and Read BAPIs for the Same Business Object
No Buffering for Read BAPIs

If write BAPIs with buffering are implemented for the same business object type, read BAPIs are not allowed to use the buffer for the same business object type, so that data read from the database can be stored, thereby avoiding further database accesses.

As the imported data is not locked, the corresponding data in the buffer would become outdated over time. Subsequent read operations would first access the buffer and read the potentially out-of-date data, as data in the database can only be read, if this data is not in the buffer.

Buffer Instances Are "Real" Instances

All instances created or changed by write BAPIs in the buffer are consistent. They can be used by other change BAPIs for further processing within the same LUW.
To guarantee the consistent behavior, all read BAPIs must handle existing instances that are in the buffer, and not yet in the database, as valid instances. Read BAPIs must be implemented in such a way that they first try to read an instance in the buffer and only start searching the database, if the instance is not found in the buffer.

A buffer instance is therefore "real" instance. For example, a BAPI ExistenceCheck() must search for the existence of an instance in the buffer also.
Documenting Read BAPIs

Each read BAPI that handles the buffering of corresponding write methods must be documented.

RELATED POSTS

BAPI SAP III

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:40:00 +0530

Defining a BAPI and Its Interface

Purpose

After you have carried out the review of the BAPI concept and it has been accepted, you can start defining the BAPI itself.

In this step, you will decide on the names, parameters, and characteristics of the BAPI and determine the structures in the ABAP Dictionary, which the BAPI will be based on. Only after you have planned and defined these required details can you start to implement the BAPI and create the required programming objects.

The table below illustrates where the planned information is written and how it fits together.

Information in the BOR, Function Builder and ABAP Dictionary

Standardized BAPIs

Use

Some BAPIs and methods provide basic functions and can be used for most SAP business object types. Such BAPIs are known as "standardized" BAPIs.

Features

With object methods and especially with BAPIs, you can differentiate between instance methods and class methods. Instance methods refer to precisely one instance (one specific occurrence) of an SAP Business Object type, for example, to one explicitly specified customer order. Whereas class methods are instance-independent.

BAPIs for Reading Data

The following BAPIs provide you with read-only access to data in the associated business object type:
GetList()
With the BAPI GetList() you can select a range of object key values, for example, company codes and material numbers. The BAPIs GetList() is a class method.

Programming GetList() BAPIs

Use

With the BAPI GetList() you can select a range of object key values, for example, company codes and material numbers. The key values returned by this BAPI can be passed on to another BAPI for further processing, for example, the BAPI GetDetail().
The BAPIs GetList() is a class method (instance-independent).

Features

Provide all the relevant fields in the interface of the GetList() BAPI. How complex and extensive you structure the interface, depends on the requirements the BAPI is to fulfill.

Import Parameters

The interface of a GetList() BAPI must provide selection parameters, in which the required selection criteria can be passed on by the calling program. The structure of selection parameters is described in the section Selection Parameters.

You must also create the parameter MaxRows that enables you to limit the number of entries selected. This parameter prevents too large a value set from being selected, if the selection parameter specification is not very precise. Use the data element BAPIMAXROW as the reference type for the MaxRows parameter.

Export Parameters

The key values selected by the BAPI GetList() are returned to the calling program in a table, together with other useful information, for example, short texts.
To report messages from the method call back to the calling program, you should create the export parameter RETURN. For more information about this parameter see
Return Parameters (Error Handling).

Extension parameters

You can create extension parameters to enable customers to enhance the functionality of BAPIs without making modifications. For information about extension parameters see Customer Enhancement Concept for BAPIs.

GetDetail()
The BAPI GetDetail() uses a key to retrieve details about an instance (one specific occurrence) of a business object type and returns this data to the calling program. Then this information is reported back to the calling program. The BAPI GetDetail() is an instance method.

Programming GetDetail() BAPIs

Use

The BAPI GetDetail() is used to read details of specific object instances.
The BAPI GetDetail() is an instance method.

Features

Import Parameters

The import parameters of the GetDetail() BAPI must contain the key fields of the business object type.

For the associated method definition in the BOR, the key fields must not also be specified as method parameters. For this reason, the BOR/BAPI Wizard does not include the function module parameters for the key fields in the method definition, when it creates a BAPI.

Export Parameters

The export parameters of a BAPI contain details of the instance. According to the amount of information, this should be structured in several parameters with meaningful names.

To report messages from the method call back to the calling program, you should create the export parameter Return. For more information about this parameter see Return Parameters (Error Handling).

Extension Parameters

You can create extension parameters to enable customers to enhance the functionality of BAPIs without making modifications. For information about extension parameters see Customer Enhancement Concept for BAPIs.

GetStatus()

The BAPI GetStatus() is used to query the status of an SAP business object instance, for example, the processing status of a sales order. This BAPI is used only for displaying the status of an object and does not retrieve full details like the BAPI GetDetail(). The BAPI GetStatus() is an instance method.

Programming GetStatus() BAPIs

Use

With the BAPI GetStatus() you can retrieve information about the status of a particular object instance.
The BAPI GetStatus() is an instance method.

Features

Import Parameters
The import parameters of the GetStatus() BAPI must contain the key fields of the business object type.

For the associated method definition in the BOR, the key fields must not also be specified as parameters. For this reason, the BOR/BAPI Wizard does not include the function module parameters for the key fields in the method definition, when it creates a BAPI.

Export Parameters

The export parameters of the BAPI contain information about the status of an object instance.

To report messages from the method call back to the calling program, you should create the export parameter RETURN. For more information about this parameter see Return Parameters (Error Handling).

Extension Parameters

You can create extension parameters to enable customers to enhance the functionality of BAPIs without making modifications. For information about extension parameters see Customer Enhancement Concept for BAPIs.

ExistenceCheck()

The BAPI ExistenceCheck() checks whether an entry exists for a business object instance, for example, whether the customer master has been created. The ExistenceCheck() BAPI is an instance method.

Programming ExistenceCheck() BAPIs

Use

The BAPI ExistenceCheck() checks whether an entry exists in the database for an SAP business object type, for example, whether the customer master has been created.
The ExistenceCheck() BAPI is an instance method.

Features

You can implement this method as a BAPI and/or as a method of SAP Business Workflow. If you implement this method as a BAPI, it only has to be implemented once, because an ExistenceCheck() BAPI can also be used by SAP Business Workflow.

To get the highest possible performance from the BAPI ExistenceCheck(), you should reduce the number of columns to as few as possible before selecting the table rows.
select single bukrs from bkpf into lv_bukrs
where bukrs = bkpf-bukrs
and belnr = bkpf-belnr
and gjahr = bkpf-gjahr.
instead of
select single * from bkpf
where bukrs = bkpf-bukrs
and belnr = bkpf-belnr
and gjahr = bkpf-gjahr.

Import Parameters

The BAPI's import parameters in the function module only contain the key fields of the business object type.

Export Parameters

To report messages from the method call back to the calling program, you should create only the export parameter Return . For more information about this parameter see Return Parameters (Error Handling).

Activities

When a business object type is created, as the default, it inherits a definition of the method ExistenceCheck() through the interface IFSAP. For this reason, you can create an ExistenceCheck() BAPI using the BOR/BAPI Wizard, as the method name ExistenceCheck() already exists for the business object type.

We recommend therefore, that you redefine the existing method ExistenceCheck() manually in the BOR, via the menu path Edit  Redefine.

• Enter the function module that implements the ExistenceCheck() BAPI.
• Create the method parameter RETURN (the key fields of the business object type are not included in the method definition in the BOR).

BAPIs for Creating or Changing Data

The following BAPIs can create, change or delete instances of a business object type:
Create() or CreateFromData()
The BAPI Create() or CreateFromData() creates an instance of an SAP business object type, for example, a purchase order. These BAPIs are class methods.

Programming Create() BAPIs

Use

The BAPI Create() creates one instance of an SAP business object type. Likewise, the BAPI CreateMultiple() creates several instances of a business object type simultaneously.

If a workflow method called Create already exists for the business object type in question, you can use the name CreateFromData() for your BAPI. Create() is the preferred name for this BAPI.

The BAPIs Create() and CreateMultiple() are class methods (instance-independent).
For each Create() BAPI a method must be provided with which the created business object instance can be deleted or cancelled. To do this, depending on the business application practice, you should implement one of the BAPIs below:

• Delete(), which deletes a business object instance from the database. For more information see Programming Delete() BAPIs.
• Cancel() which cancels a business object instance. For more information see Programming Cancel() BAPIs.

Features

Import Parameters

The BAPI's import parameters in the function module contain the data required to uniquely identify an instance. For this you can either enter all object keys or else you must ensure that these can be derived.

If required, you can also use a test run parameter to check the entry for an object instance before actually creating the instance in the database. For further information see Test Run Parameters.

You can create a change parameter to identify the values to create the instance with and to tell differentiate these values from the initial values when the BAPI is called. We recommend that you identify the change-relevant fields by flagging them.
For more information see Change Parameters.

Export Parameters

To make the object key available to the calling program, the entire key fields must be returned in the export parameters.
To report messages from the method call back to the calling program, you should create the export parameter RETURN. For more information about this parameter see Return Parameters (Error Handling).

Extension parameters

You can create extension parameters to enable customers to enhance the functionality
of BAPIs without making modifications. For information about extension parameters see Customer Enhancement Concept for BAPIs.
Avoiding Incompatibilities with Customizing Settings
It could be possible that certain values set by Customizing appear differently in the BAPI interface. These values cannot be overwritten by a Create() BAPI.
To avoid any incompatibility with Customizing settings, you should implement a Create() BAPI in the following way:

• The BAPI should transfer all the fields and check them against the Customizing settings. If the Customizing settings write-protect a field, the data in this field cannot be overwritten by data in the BAPI interface.
• For every incidence of incompatibility an error message must be returned to the calling program. For example, "Customizing settings do not allow the field 'MyAsset-AssetName' to be modified ".
• All the fields that are assigned default values by Customizing and are therefore write-protected, must be documented.

External Key Assignment
For Create() BAPIs with an external key assignment the caller transfers the key (ID) to the object instance to be created, for example, to a document number.
Keep in mind that you have to convert the specified keys explicitly in upper case letters in the source code of this type of Create() BAPIs. Otherwise keys are created that cannot be used in dialog applications. This is because with dialog applications external keys are always converted implicitly in upper case letters.

Locking

We recommend that you implement Create() BAPIs without the locking function and create your own BAPIs instead that lock the relevant data.

Change()
The BAPI Change() changes an existing instance of a SAP business object type, for example, a purchase order. The Change() BAPI is an instance method.

Programming Change() BAPIs

Use

The BAPI Change() changes an existing instance of an SAP business object type, for example, a sales order.

The BAPI Change() is an instance method, whereas the BAPI ChangeMultiple() is a class method (instance-independent).

Features

Import Parameters

The import parameters of the Change() BAPI must contain the key fields of the business object type.

If required, you can create also create these parameters:
• A test run parameter for checking the entry for an object instance before actually creating/changing the instance in the database.
• A change parameter to identify parameter fields containing modified values and parameter fields that have not been modified.
For more information about these parameters see Standardized Parameters.
Export Parameters
To make the object key available to the calling program, the entire key fields must be returned in the export parameters.
To report messages from the method call back to the calling program, you should create the export parameter RETURN. For more information about this parameter see Return Parameters (Error Handling).
Extension parameters
You can create extension parameters to enable customers to enhance the functionality of BAPIs without making modifications. For information about extension parameters see Customer Enhancement Concept for BAPIs.
Avoiding Incompatibilities with Customizing Settings
It could be possible that certain values set by Customizing appear differently in the BAPI interface. These values cannot be overwritten by a Change() BAPI.

To avoid incompatibility with Customizing settings, you should implement a Change() BAPI in the following way:

• The BAPI should transfer all the fields and check them against the Customizing settings. If the Customizing settings write-protect a field, the data in this field cannot be overwritten by data in the BAPI interface.
• For every incidence of incompatibility an error message must be returned in the return parameter to the calling program. For example, "Customizing settings do not allow the field 'MyAsset-AssetName' to be modified ".
• All the fields that are assigned default values by Customizing and are therefore write-protected, must be documented.

Locking

We recommend that you implement Change() BAPIs without the locking function and create your own BAPIs instead that lock the relevant data.

Delete() and Undelete()
The BAPI Delete() deletes an instance of an SAP business object type from the database, for example, a purchase order.
The BAPI Undelete() removes a deletion flag.
These BAPIs are instance methods.

Programming Delete() BAPIs

Use

The BAPI Delete() deletes an instance of an SAP business object type from the database. Likewise, the BAPI DeleteMultiple() deletes several instances of a business object type. Delete() BAPIs must always delete entire instances, for example, a whole material master.

(Whereas the BAPI Cancel() cancels an instance of a business object, that is the instance to be cancelled remains in the database and an additional instance is created that is canceled. For more information see Programming Cancel() BAPIs).

A delete() BAPI can delete immediately or at a later time by setting the deletion flag. The type of deletion you use in your BAPI is irrelevant to the caller, so you do not have to include these details in the BAPI interface.

The BAPI Undelete() is used to reset a deletion flag that has been set for a specific object.

The BAPIs Delete() and Undelete() are instance methods, whereas the BAPIs DeleteMutliple() and UndeleteMutliple() are class methods (instance-independent).

Features

The interfaces of the Delete() and Undelete() BAPIs should be identical.
Import Parameters
The BAPI's import parameters have to identify the business object instances to be deleted.

• If an instance is to be deleted, you have to create a parameter for each key field in the business object type.
• If several instances are to be deleted, you must create a table for the key fields of the business object type. You can do this using a range table.
If required, you can create also create these parameters:
• A test run parameter for checking the entry for an object instance before actually deleting the instance from the database.
• When the BAPI DeleteMultiple() is used, it must be possible to use the selection criteria to select the object instances to be deleted. To do this you can create selection parameters.

Implement the interface of a Delete() BAPI so that it is not possible to delete all the instances simply by parameterizing the interface, for example by specifying default settings.

Export Parameters

To report messages from the method call back to the calling program, you should create only the export parameter Return . For more information about this parameter see Return Parameters (Error Handling).

Extension parameters

You can create extension parameters to enable customers to enhance the functionality of BAPIs without making modifications. For information about extension parameters see Customer Enhancement Concept for BAPIs.

Locking

We recommend that you implement Delete() BAPIs without the locking function and create your own BAPIs instead that lock the relevant data.

Cancel()
Unlike the BAPI Delete () the BAPI Cancel() cancels an instance of a business object, that is the instance to be cancelled remains in the database and an additional instance is created that is canceled).
The Cancel() BAPI is an instance method.

Programming Cancel() BAPIs
Use
The Cancel() BAPI cancels one instance of a business object.
Unlike the BAPI Delete(), which deletes an object instance from the database, with the BAPI Cancel():

• The canceled instance of the business object is not deleted
• An additional instance is created with which the instance of the business object is deleted
The Cancel() BAPI is used to cancel business processes such as goods movements or invoice receipts.
The Cancel() BAPI is an instance method.

Features

Import Parameters

The data of the instance to be created comes from the data of the business object instance to be cancelled.

You can also create further parameters to specify information relevant for the actual cancellation process, for example, the name of the user performing the cancellation.

If required, you can also create a test run parameter, which can check the details of the object instance before it is actually canceled. For more information about this parameter see Test Run Parameters.

Export Parameters

To report messages from the method call back to the calling program, you should create the parameter Return. For more information about this parameter see Return Parameters (Error Handling).
You have to put the key of the created instance in another export parameter.
Locking
We recommend that you implement Cancel() BAPIs without the locking function and create your own BAPIs instead that lock the relevant data.

Add and Remove

The BAPI Add adds a sub-object to an existing object instance and the BAPI and Remove removes a sub-object from an object instance. These BAPIs are instance methods.

BAPI SAP II

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:39:00 +0530

BAPI Explorer

Definition

The BAPI Explorer is the R/3 System working environment for developing BAPIs themselves and for developing with BAPIs.

Use

Prerequisites
The BAPI Explorer is available as of Release 4.6A and enhances or replaces the BAPI Browser used in earlier releases. The BAPI Explorer uses the latest HTML control technology. For this reason to work with the BAPI Explorer, you must be using a SAPgui of version 4.6A.

If you are using a SAPgui from an earlier release, the BAPI Browser (Transaction BAPI45) is automatically called instead of the BAPI Explorer. For information about working in the BAPI Browser see BAPI Browser in the BAPI User Guide.

Purpose

In the BAPI Explorer, application developers can get an overview of the status of BAPIs in the BOR. The BAPIs can be determined either by the position of the associated object or interface type in the component hierarchy in the BOR, or from an alphabetical list. All information required to use a particular BAPI is provided in the BAPI Explorer.

The BAPI Explorer is used internally in SAP to develop BAPIs, but can also be used by customers and partners. The BAPI Explorer provides all the tools used to create BAPIs and the required development objects in an integrated programming environment. The entire development process of a BAPI takes place in the framework of form-controlled "projects" to achieve maximum quality, stability and usability of the BAPI.

Structure

The BAPI Explorer is divided into two areas:

• Hierarchy display
Here all the business object types or interface types for which BAPIs have been defined are displayed. For further information see Working with Display Functions.
• Work area
Here the details and documentation of the development object selected in the hierarchy display can be viewed.
The tools used to develop BAPIs are also available in the work area. For further information see Working with Tools and Projects.

Integration

To call the BAPI Explorer choose Tools  Business Framework  BAPI Explorer. To call it directly use Transaction BAPI.

Working with Display Functions

Use
In the hierarchy display of the BAPI Explorer all the business object types or interface types for which BAPIs have been defined are displayed.
Using the tabs Alphabetical and Hierarchical in the hierarchy display, you can select whether the business object types or interface types are displayed alphabetically or as they are assigned in the component hierarchy in the BOR.
By expanding the relevant nodes you can navigate up to the parameter level of individual BAPIs.

Features
The following display functions are also provided which enable you to directly access BAPIs and their details in the BOR.

• Displaying details
Under the Detail view of the work area all the technical details of the development object selected in the hierarchy are displayed.
In most cases you can double-click on a field in the Detail display to get to the development environment or to display further information. For example, in the detail display for a particular method, by double clicking on the name of the function module, it will be displayed in the Function Builder.
• Displaying and Printing Documentation
In the Documentation view of the work area the documentation for the development object selected in the hierarchy is displayed.
The data element documentation for each parameter field is contained in the documentation for structured BAPI parameters.

If you have installed Microsoft Internet Explorer Version 4.0 on the front-end computer, you can print the documentation using the standard SAPgui print function.

• Changing the level of the hierarchy display
The component hierarchy may have many hierarchy levels. To make it easier to find a business object type and its BAPIs, you can use the function Goto  Change hierarchy level to limit the display to two hierarchy levels.

• Specifying the BAPIs to be displayed
The default is to display only released BAPIs of business object types. By choosing Goto  BAPIs to display, you can display all the BAPIs contained in the BOR, that is BAPIs of SAP interface types and BAPIs that have not yet been released.
Business object types and interface types are identified by different symbols. To display these, choose Goto  Display legend.

• Searching for BAPIs
Using the standard functions Find and Find next you can search the displayed business object types or interface types using specified criteria (placeholders such as ' * ' can be used):

• Object name, e.g. Business Process
• Object type (technical object name) e.g. SAP0001
• Object description, e.g. Plan*
• Method name, e.g. GetList
• Method description, e.g. object list*

Working with Tools and Projects

Use

The views Tools and Projects in the work area are mainly used for developing BAPIs.

Features
Depending on the development object selected in the hierarchy display, in the Tools view, the following tools and navigation options are provided:
• Direct access to the Business Object Builder, Function Builder and ABAP Dictionary.
• List generator to create lists of BAPIs using specified selection criteria.
In the Project view you can create projects to assist you with following and documenting the development procedures below:

• Implementing new BAPIs (for internal SAP use, BAPI developments must be carried out and documented using a project in the BAPI Explorer)
• Changing released BAPIs (only for SAP internal use)
• Requesting a new business object type (only for SAP internal use)
For each of these projects there is a project form that takes you step by step through the entire development process and provides direct navigation options to the required development tools and information.
Within the project management you can save and delete your projects and you can edit the projects managed by other users by selecting other users.
If you have installed Microsoft Internet Explorer Version 4.0 on the front-end computer, you can print the project form using the standard SAPgui print function.

Defining the Scenario

Purpose

Before you program a BAPI you should clearly define the processes and situations the BAPI will be used for. BAPIs should only be implemented within the context of a meaningful business scenario.

For examples of BAPI scenarios refer to Overview of ALE Integration Scenarios in the Library of ALE Business Processes. SAP developers will also find templates for defining and documenting BAPI scenarios.

Process Flow

To define the scenario the BAPI is to be used in, consider the following issues:

• Which scenario is to be implemented?
Every BAPI should be based on a model of a scenario in which it can be usefully employed.
Keep in mind whilst you are planning the scenario that COMMIT WORK commands must not be used in BAPIs. COMMIT WORK commands can adversely effect the process flow of the scenario and how the BAPIs in the scenario work together.
• Which SAP business object types are required and do they exist?
From the scenario definition you can get information about the SAP business object types relevant to the BAPI scenario. If the business object types required do not exist, they must be created. For information about creating SAP business object types see the documentation, SAP Business Workflow. For SAP internal development you have to complete a business object request form in the BAPI Explorer.

A BAPI is required to read the data of a company code. First of all, a list of all company codes is to be displayed. From this list a company code can be selected, and then using another BAPI, details about this company code are to be displayed.
The relevant SAP business object type for this scenario is Company Code.

• What functionality should the BAPI provide and how does it affect related BAPIs, especially the other BAPIs of the SAP business object type in question?
In line with the scenario concept, BAPIs must complement each other to create a complete scenario. Their relationships with each other must be clearly defined.

To read the details of a company code as described in the above example scenario, two BAPIs are required:

• To display all the company codes
• To display a specific company code
The interdependency between these two BAPIs is evident because first the list of company codes is displayed to obtain the ID of the specific company code sought. From this ID details of the company code can be displayed.
However, the two BAPIs remain functionally independent of each other, because if the company code ID is known, the BAPI "Display details of a specific company code" can be used without first calling the BAPI "Display list of all company codes".
• To what extent can the BAPI's functionality be implemented within the scope of the business object?

A BAPI should be developed so that it provides functionality exclusively within the context of its associated SAP business object type. If the data of a different SAP business object type is to be read or updated then the appropriate interface for this object type must be used. The functions or methods of these other object types are used implicitly.

The BAPIs required to read the details of a company code in the above example scenario are only able to access data in the SAP business object type Company Code. Other object types are not involved.

• Is the BAPI assigned to the SAP business object type in a meaningful and semantically correct way?
Result
Once you have considered these issues you will be able to clearly conceptualize the functionality of the planned BAPI(s). You will also have identified the SAP business object types relevant to the BAPI scenario.

RELATED POSTS

BAPI SAP I

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:38:00 +0530

Definition

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 of SAP Business Object Types
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.

BAPIs of SAP Interface Types

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.

Integration

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

BAPIs - Interfaces to the R/3 System

BOR

Definition

The Business Object Repository (BOR) is the object-oriented repository in the R/3 System. It contains the SAP business object types and SAP interface types as well as their components, such as methods, attributes and events.

BAPIs are defined as methods of SAP business object types (or SAP interface types) in the BOR. Thus defined, the BAPIs become standard with full stability guarantees as regards their content and interface.
For general information on creating business objects see the documentation on SAP Business Workflow.

Use

The BOR has the following functions for SAP business object types and their BAPIs:

• Provides an object-oriented view of R/3 System data and processes.
R/3 application functions are accessed using methods (BAPIs) of SAP Business Objects. Implementation information is encapsulated; only the interface functionality of the method is visible to the user.
• Arranges the various interfaces in accordance with the component hierarchy, enabling functions to be searched and retrieved quickly and simply.
This finds the functionality searched for quickly and simply.
• Manages BAPIs in release updates.

BAPI interface enhancements made by adding parameters are recorded in the BOR. Previous interface versions can thus be reconstructed at any time. When a BAPI is created the release version of the new BAPI is recorded in the BOR. The same applies when any interface parameter is created.

The version control of the function module that a BAPI is based on is managed in the Function Builder.

• Ensures interface stability.
Any interface changes that are carried out in the BOR, are automatically checked for syntax compatibility against the associated development objects in the ABAP Dictionary.

Integration

A BAPI is implemented as a function module that is stored and described in the Function Builder. You should only define a BAPI as a method of an SAP business object type in the BOR, if the function module that the BAPI is based on has been fully implemented.

Access to the BOR is restricted at SAP.
BOR/BAPI Wizard
The BOR/BAPI Wizard helps you to create new BAPIs in the BOR. It takes you through the process step by step.

Defining and Implementing the BAPI

Purpose

Various components of the ABAP Workbench are used when you define and implement a BAPI. These are shown in the graphic below.

BAPIs are defined in the Business Object Repository (BOR) as API methods of SAP business object types. BAPIs are implemented in the Function Builder as RFC-enabled function modules. The definitions and descriptions of the data structures used by the BAPI are stored in the ABAP Dictionary.

BOR, Function Builder and ABAP Dictionary

Prerequisites

For function modules that implement BAPIs, certain standards and rules must be adhered to over and above the standard programming rules for function modules.

The following sections guide you through the steps involved in developing a BAPI. The sections contain information about the guidelines and conventions that you should adhere to when defining and implementing a BAPI. When implementing BAPIs follow the requirements below to ensure you achieve consistent behavior and representation of BAPIs as object-oriented methods of SAP business object types or SAP interface types.

RELATED POSTS

TABLE CONTROL IN BDC

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:37:00 +0530

Steploop and table contol is inevitable in certain transactions. When we run BDC for such transactions, we will face the situation: how many visible lines of steploop/tablecontrol are on the screen?

Although we can always find certain method to deal with it, such as function code 'NP', 'POPO', considering some extreme situation: there is only one line visible one the screen, our BDC program should display an error message. (See transaction 'ME21', we you resize your screen to let only one row visible, you can not enter mutiple lines on this screen even you use 'NP')

we can determine the number of visible lines on Transaction Screen from our Calling BDC program.

Demo ABAP code has two purposes:

1. how to determine number of visible lines and how to calculte page number;
(the 'calpage' routine has been modify to meet general purpose usage)

2. using field symbol in BDC program, please pay special attention to the difference
in Static ASSIGN and Dynamic ASSIGN.

Step1: go to screen painter to display the screen 121, then we can count the fixed line on this screen, there is 7 lines above the steploop and 2 lines below the steploop, so there are total 9 fixed lines on this screen. This means except these 9 lines, all the other line is for step loop.

Then have a look at steploop itselp, one entry of it will occupy two lines.
(Be careful, for table control, the head and the bottom scroll bar will possess another two fixed lines, and there is a maximum number for table line)
Now we have : FixedLine = 9
LoopLine = 2(for table control, LoopLine is always equal to 1)

Step2: go to transaction itself(ME21) to see how it roll page, in ME21, the first line of new page is always occupied by the last line of last page, so it begin with index '02', but in some other case, fisrt line is empty and ready for input.
Now we have: FirstLine = 0
or FirstLine = 1 ( in our case, FirstLine is 1 because the first line of new page is fulfilled)

Step3: write a subroutine calcalculating number of pages
(here, the name of actual parameter is the same as formal parameter)

global data: FixedLine type i, " number of fixed line on a certain screen
LoopLine type i, " the number of lines occupied by one steploop item
FirstLine type i, " possbile value 0 or 1, 0 stand for the first line of new " scrolling screen is empty, otherwise is 1
Dataline type i, " number of items you will use in BDC, using DESCRIBE to get
pageno type i, " you need to scroll screen how many times.
line type i, " number of lines appears on the screen.
index(2) type N, " the screen index for certain item
begin type i, " from parameter of loop
end type i. " to parameter of loop

*in code sample, the DataTable-linindex stands for the table index number of this line

form calpage using FixedLine type i (see step 1)
LoopLine type i (see step 1)
FirstLine type i (see step 2)
DataLine type i ( this is the item number you will enter in transaction)
changing pageno type i (return the number of page, depends on run-time visible line in table control/ Step Loop)
changing line type i.(visible lines one the screen)
data: midd type i,
vline type i, "visible lines
if DataLine eq 0.
Message eXXX.
endif.

vline = ( sy-srows - FixedLine ) div LoopLine.
*for table control, you should compare vline with maximum line of
*table control, then take the small one that is min(vline, maximum)
*here only illustrate step loop

if FirstLine eq 0.
pageno = DataLine div vline.

if pageno eq 0.
pageno = pageno + 1.
endif.
elseif FirstLine eq 1.
pageno = ( DataLine - 1 ) div ( vline - 1 ) + 1.
midd = ( DataLine - 1 ) mod ( vline - 1).
if midd = 0 and DataLine gt 1.
pageno = pageno - 1.
endif.
endif.

line = vline.

endform.

Step4 write a subroutine to calculate the line index for each item.

form calindex using Line type i (visible lines on the screen)
FirstLine type i(see step 2)
LineIndex type i(item index)
changing Index type n. (index on the screen)

if FirstLine = 0.
index = LineIndex mod Line.
if index = '00'.
index = Line.
endif.
elseif FirstLine = 1.
index = LineIndex mod ( Line - 1 ).
if ( index between 1 and 0 ) and LineIndex gt 1.
index = index + Line - 1.
endif.
if Line = 2.
index = index + Line - 1.
endif.
endif.

endform.

Step5 write a subroutine to calculate the loop range.

form calrange using Line type i ( visible lines on the screen)
DataLine type i
FirstLine type i
loopindex like sy-index
changing begin type i
end type i.

If FirstLine = 0.
if loopindex = 1.
begin = 1.
if DataLine <= Line. end = DataLine. else. end = Line. endif. elseif loopindex gt 1. begin = Line * ( loopindex - 1 ) + 1. end = Line * loopindex. if end gt DataLine. end = DataLine. endif. endif. elseif FirstLine = 1. if loopindex = 1. begin = 1. if DataLine <= Line. end = DataLine. else. end = Line. endif. elseif loop index gt 1. begin = ( Line - 1 ) * ( loopindex - 1 ) + 2. end = ( Line - 1 ) * ( loopindex - 1 ) + Line. if end gt DataLine. end = DataLine. endif. endif. endif. endform. Step6 using field sysbol in your BDC, for example: in ME21, but you should calculate each item will correponding to which index in steploop/Table Control form creat_bdc. field-symbols: , , .

data: name1(14) value 'EKPO-EMATN(XX)',
name2(14) value 'EKPO-MENGE(XX)',
name3(15) value 'RM06E-SELKZ(XX)'.
assign: name1 to ,
name2 to ,
name3 to .
.
do pageno times.

if sy-index gt 1

*insert scroll page ok_code"

endif.
.
.
perform calrange using Line DataLine FirstLine sy-index
changing begin end.
.
.
loop at DataTable from begin to end.
perform calindex using Line FirstLine DataTable-LineIndex changing Index.
name1+11(2) = Index.
name2+11(2) = Index.
name3+12(2) = Index.
.
.
perform bdcfield using DataTable-matnr.
perform bdcfield using DataTable-menge.
perform bdcfield using DataTable-indicator.
.
.
.

endloop.

enddo.

RELATED LINKS

USER EXITS IN DETAIL

anushaads@gmail.com (Technical Information) — Wed, 11 Mar 2009 11:35:00 +0530

In computer software, a user exit is a place in a software program where a customer can arrange for their own tailor-made program to be called.

In the R/3 system from SAP, a user exit is contrasted with a customer exit and allows a customer's developer to access program components and data objects within the R/3 system. In R/3, some user exits use Include statements to include customer program enhancements that are called from the program.

Other user exits use tables that are accessed through customization.

Overview

Extension of SAP functionality

SAP makes different possibilities available to extend SAP functionality in the R/3 without modifying the delivered R/3-Standard. Thus these extensions are further present also after a R/3-Release-Wechsel.

• User exit
• Field exit
• Text extensions
• Customer exit
• Table extensions

1. User exit

User exits are original one in the selling module (SD) developed expandability.
They consist of empty subroutines (FORM) in special Includes, which can be filled by a ABAP Use developer.

In special places in the SA P-CODE such subroutine references were inserted by SAP. An extension is thus only possible, where SAP planned it.

They usually offer a rather rudimentary expandability, since purely technically objects in the SAP name area are modified.

2. Field exit

Field exits are bypasses of a Dynprofield with data element purchase into a functional module. These will go through when leaving the Dynpros. There are global and local field exits.

Global field exits

are not limited to a Dynpro. If a data element is used on several Dynpros, after activation of the field exit with all this Dynpros to a functional module one branches out.

Local one field exit

work only on a Dynpro limited. There is the possibility of putting on bus to 36 local field exits to a data element.
3. Text extensions
With text extensions it acts around user keywords and user documentation (F1-Hilfe) to data elements. The new keywords can refer to SAP documentation and to user documentation. Thus one has also the possibility of overwriting the keywords delivered by SAP.
With text extensions the changes are global effective for all SAP applications concerned contrary to application extensions after activation.
4. Customer exit
An application function can be extended by application extensions by the customer. Customer exits must be intended by SAP. They consist generally of several components. The interface SAP/Kunde is clearly defined.
With a R/3-Release-Wechsel and/or. Upgrade remain the customer extensions without effort.

• Function exit
• Menu exit
• Dynpro exit

A) Function exit
By functional module exits the customer can implement additional logic in an application function.
SAP built such exits in different places into many application functions. Thus are the interfaces are already given, and/or which data handed over.
These functional modules can be filled now by the customer. It can insert also user Dynpros with associated processing logic and GUI surface and put on user text elements.

B) Menu exit

Menu exits make it for the customer possible to build and occupy with a function code in an SAP application new menu entries.
SAP determined, where in the program additional function codes are queried and like to it is being reacted, either by a functional module exit or by an already firmly given functionality.

C) Dynpro exit

Dynpro exits permit the customer to arrange ranges of a dynpros reserved by SAP. Within these ranges large information can be indicated or data be seized. Those for this force fields by the customer on a user Dynpro are arranged.

In Details

What is User Exits?

The following document is about exits in SAP: -
The R/3 enhancement concept allows you to add your own functionality to SAP’s standard business applications without having to modify the original applications.
SAP creates user exits for specific programs, screens, and menus within standard R/3 applications.
These exits do not contain any functionality. Instead, the customer exits act as hooks. You can hang your own add-on functionality onto these hooks.

Types of Exits

There are several different types of user exits. Each of these exits acts as hooks where you can attach or "hang" your own add-ons.

Menu Exits

Menu exits add items to the pulldown menus in standard SAP applications. You can use these menu items to call up your own screens or to trigger entire add-on applications.
SAP creates menu exits by defining special menu items in the Menu Painter. These special entries have function codes that begin with "+" (a plus sign). You specify the menu item’s text when activating the item in an add-on project.

Screen Exits

Screen exits add fields to screens in R/3 applications. SAP creates screen exits by placing special subscreen areas on a standard R/3 screen and calling a customer subscreen from the standard screen’s flow logic.

Function Module Exits

Function module exits add functions to R/3 applications. Function module exits play a role in both menu and screen exits.
When you add a new menu item to a standard pull down menu, you use a function module exit to define the actions that should take place once your menu is activated.
Function module exits also control the data flow between standard programs and screen exit fields.

SAP application developers create function module exits by writing calls to customer functions into the source code of standard R/3 programs.
These calls have the following syntax:

CALL CUSTOMER-FUNCTION ‘001’.

Field Exits

Field exits allow you to create your own programming logic for any data element in the Dictionary. You can use this logic to carry out checks, conversions, or business-related processing for any screen field. Example: The data element BBBNR identifies a company’s international location number. You might want to set up your R/3 System so that all international location numbers are larger than 100.
The field exit concept lets you create a special function module that contains this logic.
You assign the special function module to the data element BBBNR. You then assign the module to any programs and screens in which users can add new international location numbers. When you activate your field exit, the system automatically triggers your special routine whenever a user enters a company location number.
In 4.6c, you can use "RSMODPRF" program to create field exits.
An example of a user exits :-
MODULE user_exit_0001 INPUT
CASE okcode.
WHEN 'BACK OR EXIT'.
CASE sy-dynnr.
WHEN '100'.
SET SCREEN 0.
LEAVE SCREEN.
WHEN '200'.
******************************************************************************
**** Note that you can write any code that satisfy your needs. ****
**** But in this case, this was wrote as a sample code for reference sake. ****
**** And you can test it. ****
******************************************************************************
SET SCREEN 100.
LEAVE SCREEN.
ENDCASE.
ENDCASE.

SAP User Exits Routine

User exits are routine which SAP allows you to add in additional customized programs process without affecting the standard SAP programs.
SAP user exit are usually declare as a form routine :-
form userexit_xxxxx
........................
endform
In VL01 - Create Delivery Order, standard program SAPMV50A, the standard program did not check for storage location equal to space, and delivery quantity less than one when the user click the save button. Therefore I have to insert the additional checking into the userexit routine.

Steps:-

• Goto transaction VL01 to pick a Sales Order for delivery (you don't have to save the data)
• In the initial screen, click System -> Status -> Double click on Program (Screen)
• In the dialog program SAPMV50A, click Edit -> Search/replace
• Type userexit in the Find field, then click the In program radio button and hit Enter
• A number of userexit routines will be displayed. You'll have to roughly decide which is the correct userexit routine to used.
Another way of determining the list of user exits could be bus executing the Tcode SE80.
For example if U need to search for the user exits for the above mentioned program, execute the Tcode SE80 and enter the above program name,

The highlighted row denotes a user exit, which is used in this program
form userexit_save_document_prepare.
case xlips-pstyv.
when 'TAX' or 'REX'.
* Accept this two Delivery item category
when 'REN'.
if xlips-lgort = space.
* Reject this Delivery item category
message e001.
endif.
when others.
if xlips-matnr <> space.
* Check storage location not space
if xlips-lgort = space.
message e002.
endif.
* Check delivery quantity not zero
if xlips-pikmg < pgmid =" 'R3TR'" object =" 'PROG'" obj_name =" tstc-pgmna." name =" tstc-pgmna." pname =" tstc-pgmna." funcname =" tfdir-funcname." pgmid =" 'R3TR'" object =" 'FUGR'" pgmid =" 'R3TR'" object =" 'SMOD'" devclass =" v_devclass." sprsl =" sy-langu" name =" jtab-obj_name." zzzz =" up">Bus.transactions->Base parameters->Validation
/NORFB->Bus.transactions->Base parameters->Substitution
Example
=ULTE "FI_DOCU 001 "Parked SA,FY,SI=>long text CORRESP. "

=U&VALID_WBS_IN_ZUONR "FI_ITEM 011 Spon.Res: Check WBS valid in ZUONR"

* changed in 4.5B (* Form UFIA -- formerly U&VALID_WBS_IN_ZUONR)
User exits are form routines that the user programs. There are two types of

user-exits:

1. Validation exits are used in the prerequisites and checks. They have either the value 'T' for true or 'F' for false. They are interpreted as a part of the logical statement, like a constant or field comparison. For this type of user exit, you must fill a parameter with the results of your check ('T' for true; 'F' for false).
Example
FORM Uzzzz USING B_RESULT. "'T' or 'F'
from program ZGGBR000 (ZGGBRI03)
2. Substitution exits are used to change one or more fields. However, you can only change those fields that are permitted in the Boolean class for the substitution. You can display these fields by selecting the following menu options in substitution maintenance: Fields for substitutions>
Example
FORM Uzzzz USING COST_CENTER.
from program ZGGBS000 (ZGGBSI02)
Substitution Fields can be found from this window

/NORFB->Bus.transactions->Base parameters->Substitution->Call Pnt 2->Substitution step 3->Extras->Substitution flds
The name of the form pool (e.g., ZGGBR000 & ZGGBS000) that contains your user exit must be stored in table T80D.
Note
1. Data declaration
Tables and field stings cannot be declared in form routines, so that the contents can be used along with the calling transaction.
2. Parameter definition
It is important that you make declare the code generation program for your user exit; how many and what type of parameters you are using for the user exit. You do this by entering your newly defined user exits in the form routine GET_EXIT_TITLES.
found in program ZGGBR000 (ZGGBRTIT)
found in program ZGGBS000 (ZGGBSTIT)
One exception is the parameter for the results of a validation exit. You must not declare this, it is automatically generated be the system. What types of parameters are available and how you use them is described in the online documentation. When creating your user exits, you can use the example form pools delivered by SAP (RGGBR000 for validations; RGBBS000 for substitutions) as a reference. We recommend that you copy the example form pools delivered by SAP when creating your own user exits. In these example form pools, entries already exist in the form routine GET_EXIT_TITLES for the examples delivered. The GET_EXIT_TITLES must absolutely exist in your form pool.
You can find additional information on the creation of user exits in the online documentation on validations and substitutions.
SAP exits
SAP exits are form rountines programmed by SAP. The name of the form pool is SAPFGBEB.
Syntax:
=Szzzz (zzzz = up to four characters)
FORM Szzzz using B_result. "'T' or 'F'
Example
=S01 "SAP exit S01"
Display description of T80D configuration
Return ->
Change Validation: FI_ITEM (Message view)

RELATED POSTS