Solved: Regarding BAPI AND ALE

Former Member · ‎07-04-2007

Hi..

I hav few doubts ...

I want to know how to create Bapi using swo1 and use in BOR.

what are the steps for ALE.

Thanks& Regards,

kavita

Former Member · ‎07-04-2007

Hi,

SAP's Business Object Repository gives you an improved way to integrate business processes with external partners -- an increasingly necessary ability in the burgeoning e-marketplace economy.

by Alon Raskin

The age of e has had a profound effect on the IT industry. Not only has it changed our way of life, but it has also forced systems such as SAP to embrace a new era of openness. Marketplace demands for flexible automation of inter-business workflow and intelligent data exchange have forced formerly very proprietary ERP systems to begin helping customers integrate with other companies and with e-marketplaces data formats. For the first time, companies must expose their business processes to the outside world.

In order to achieve this openness, SAP provides a technical infrastructure for the R/3 product, the Business Object Repository (BOR), which provides a simple yet powerful mechanism for external systems to trigger core business processes (such as placing an order) without concern for the underlying data structure. This level of abstraction is beneficial because it decouples R/3 from the external system. Either system is therefore free to change its internal business processes without affecting the other. SAP provides this technical infrastructure using a component-based view of its system. Each component or object provides a view of the data and the business processes that interact with that data. External systems can access this data via BAPI methods, which in turn access the underlying data structures of the system. It is the responsibility of the object and the BAPI to ensure the integrity of the data. This encapsulation of the data not only lends itself to external interfaces, but by using objects from within SAP, you can greatly reduce implementation, testing, and maintenance effort via the promotion of code reuse.

Business Objects

A business object is a problem-domain entity that you model in the SAP system, such as SalesOrder, BillingDocument, and Employee. The BOR stores all the objects in the R/3 system. The repository is a group of all the objects in the R/3 system. If the focus of objects is to model atomic business processes then it can be said that the BOR provides an enterprisewide view of business processes. By designing your ABAP code to fit your business processes you increase the ability of that code to flex when those processes are altered or integrated with external systems. This had made the object-oriented approach, which the BOR provides, essential to developing inter-business or e-business functionality.

Attributes

A business object is primarily represented by its attributes. You perform actions, such as create, update, or delete on the attributes by calling the methods of the object.

Attribute NetValue of Object BUS2032 (SalesOrder).

The majority of attributes are data-dictionary fields (for example, the NetValue attribute is defined by VBAK-NETWR). When you access an attribute of an object, you execute a SQL statement that retrieves the corresponding field in the database.

Definition of attribute NetValue.

You can also define attributes that do not exist in the data dictionary. These attributes are called virtual attributes. For example, a business partner has an attribute called BirthDate that is stored in the data dictionary. You can add a virtual attribute to the BusinessPartner object called Age. The age of a business partner is not stored in the database, but you can calculate it using the current date and the birth date of the business partner. If you implement the ABAP code that calculates Age, every time you access the Age attribute, the code executes and returns the business partners age.

Definition of virtual attribute Age.

This is an excellent example of one of the tools that a component-based approach provides. The external system does not need to concern itself with how to gather the data that it requires. The calling program needs only to access the attribute for the data to be returned. This is how business objects decouple the calling program (whether it be in R/3 or external to R/3) from the internals of R/3.

The BOR lets you define multi-line attributes. These attributes define one-to-many relationships between an object and other fields. These objects can be defined in the data dictionary or can also be virtual attributes.

An attribute that uniquely defines an object in the system is called a key attribute. In the case of a SalesOrder, the key attribute is VBAK-VBELN (the TableName and FieldName). It is not uncommon for an object to have several key fields. An example of this is object is the SalesArea (BUS000603) object type which has SalesOrganization (TVTA-VKORG), DistributionChannel (TVTA-VTWEG) and Division (TVTA-SPARTE) as key fields.

Methods

As mentioned earlier, the methods of an object represent the actions you take with objects attributes. An action in this example would include retrieving the status of one or more sales orders based on specific criteria. Methods are analogous to function modules in that they have importing and exporting parameters as well as exceptions, which you view by selecting a method and clicking on the toolbar button. This allows external systems (or internal developments) to pass and accept parameters from these methods just as if they were using function modules -- allowing external systems to call methods.

In Figure 4, the methods shown with the green LED are BAPIs that are called specifically from external systems. They can, however, be called from within the system itself. The method shown with the stop sign is obsolete, but retained for backward compatibility, and should not be used in new developments.

Methods of SalesOrder.

Delegation and Subtyping

One of the most complex concepts in object-oriented development is that of inheritance. This concept lets you extend core functionality by creating a child of the parent object that inherits all of its attributes and methods. For example, a Manager object is a subtype (child) of the Employee object. The Manager object has all the attributes of an Employee object (such as EmployeeID or Name) but also has some extra attributes (such as CompanyCar or ParkingSpace). SAP has not implemented inheritance in the BOR. However, it has provided subtyping and delegation, which offer an alternative way to extend R/3 functionality.

Subtyping

A subtype of an object is another object whose creation is based upon a parent object (see the preceding manager/employee example). The subtype maintains references to all the attributes and methods of its parent object. This means that any methods and attributes defined on the parent can be executed and accessed on the child object. I have often heard less-experienced developers refer to subtyping as copying the parent object. Although the effects can be similar, in order to achieve an understanding of some of the more advanced concepts, such as interface inheritance, it is important to realize that this is not accurate.

If a subtype object were merely a copy of its parent, then all the code contained within the parent would be physically copied to the child. This is not the case. The subtype simply maintains references to its parents methods and attributes. The real difference is that the subtype lets you redefine these methods and attributes. You can easily add your own business rules to the parent methods by redefining the subtypes method. In the following example, I will show why this distinction is so important.

Subtyping Case Study

As an ABAP developer at Acme Tyres Pty. Ltd., you have been given the task of implementing some security measures for the companys online store. The requirement is simple: The password must be at least six characters long.

Modifying SAP code leads to costly and complicated upgrades due to the modified code being overwritten by the newly delivered SAP code. Therefore, The challenge is finding a way of implementing the business logic without modifying SAP code.

After some investigation, you realize that the method CHANGEPASSWORD (in BAPI) on the object KNA1 (Customer) is called when customers change their passwords. All you need to do is create a subtype of KNA1 and then redefine the CHANGEPASSWORD method adding the ABAP code to ensure that the password is a minimum of six characters long. It is of course not wise to change SAP code even assuming you have the passwords, which can be provided only be SAP. After the method is redefined, you just need to implement the business rules in ABAP.

FIGURE 5 Redefinition of ChangePassword method.

It is imperative that once you redefine the method it still behaves in a similar manner. You are allowed to add extra business logic, but the method must still change the password rather than do something unexpected, like delete a customer. This is particularly important when SAP is being accessed from external systems. The external system will expect a method to provide certain functionality. The developer should take care to ensure that this expectation is met.

Delegation

Now that you have implemented a new CHANGEPASSWORD method, you need to tell the SAP system to use the redefined version of CHANGEPASSWORD and not the version that was delivered on the KNA1 object. This is similar to object-oriented inheritance but the two concepts do have fundamental differences.

Delegation for objects.

By making an entry in the delegation table, you tell R/3 that before executing a method on KNA1, it should first check if that method has been redefined on the subtype. If it has, then the system executes the redefined method . If it hasn't, then the system executes the original method. Figure 7 illustrates this process.

Execution flow for methods with delegation.

This delegation is powerful because it lets you implement your own business logic without modifying any SAP code. As long as the objects are properly delegated, your method will be executed.

Responsibility

So far I have shown you two major components of an object, its attributes and methods. The difficulty in SAP is that it has traditionally been a data-driven, procedural-development approach. The BOR is not well understood by developers and managers and thus it is shunned by those that stand to gain the most from it. If managers and developers alike would take a formalized approach to development using business objects, significant savings in the development, testing, and maintenance phases would be achieved. This is due to the high level of re-use that business objects encourage.

Having said this, when a powerful tool is put into the hands of an inexperienced person, chaos can (and usually does) ensue. If object-oriented design principals are not adhered to, then the resulting code has poor reusability and maintainability. Although an in-depth discussion of design issues is beyond the scope of this article, I will introduce in the following section one of the more fundamental design aspects of BOR programming: Responsibility.

When you are given the task of creating a method or attribute on an object, one of the most important questions you should ask is, Does this attribute or method belong on this object? This question is fundamental to an object-oriented design and the answer can make a world of difference. Answering this question incorrectly has detrimental effects on the development effort resulting in methods and attributes strewn across myriad objects, with no coherent structure. If the methods and attributes were strewn across several objects, it would be more difficult to provide a uniform interface to external systems. If an external system wants to execute a particular business process in R/3, it may need to access several business objects, thus increasing coupling and reducing the layer of abstraction between R/3 and the external system.

Lets take, for example, the requirement to be able to update a sales order. This is a common requirement and one that SAP usually implements for you. For the sake of the example, lets assume that SAP has not implemented this method. You will need to implement your own UPDATE method on one of the business objects. The question here is: Which object? This question is what I term as defining responsibility. Which object is responsible for having the UPDATE method on it? As shown in Figure 4, the answer in this cases is BUS2032 (SalesOrder). If you put it on any other object then you run the risk of no one else knowing of its existence. Next time there is a requirement to update a sales order, the developer will develop an additional method. You would then have two separate pieces of code that implement the same functionality. This duplication doubles development, testing, and maintenance requirements. On large projects, this can become a real problem and a maintenance and testing nightmare.

SAP recognizes the challenges facing developers in the e-business era. It is aware that if it wants to take R/3 to the next phase, it needs to continue evolving the ABAP language and ensure that powerful development tools are available to SAP developers.

Rising to the challenge, SAP has begun developing extensions to the ABAP language called ABAP objects (see "Introducing ABAP Objects," in the IntelligentERP feature archive for an excellent introductory article to ABAP objects by Jürgen Heymann and Horst Keller). These extensions will provide ABAP developers with a full range of object-oriented tools. Eventually, these new extensions will make BOR obsolete. However, the use of object-oriented development is sure to be an integral part of future SAP developments, regardless of where the world of e takes us.

ALE-STEPS

ALE IDOC

Sending System(Outbound ALE Process)
Tcode SALE ? for
a) Define Logical System
b) Assign Client to Logical System
Tcode SM59-RFC Destination
Tcode BD64 ? Create Model View
Tcode BD82 ? Generate partner Profiles & Create Ports
Tcode BD64 ? Distribute the Model view

Message Type MATMAS
Tcode BD10 ? Send Material Data
Tcode WE05 ? Idoc List for watching any Errors

Receiving System(Inbound ALE )
Tcode SALE ? for
a) Define Logical System
b) Assign Client to Logical System
Tcode SM59-RFC Destination

Tcode BD64 ? Check for Model view whether it has distributed or not
Tcode BD82 -- Generate partner Profiles & Create Ports
Tcode BD11 Getting Material Data
Tcode WE05 ? Idoc List for inbound status codes

ALE IDOC Steps

Sending System(Outbound ALE Process)
Tcode SALE ?3 for
a) Define Logical System
b) Assign Client to Logical System
Tcode SM59-RFC Destination
Tcode BD64 !V Create Model View
Tcode BD82 !V Generate partner Profiles & Create Ports
Tcode BD64 !V Distribute the Model view

This is Receiving system Settings

Receiving System(Inbound ALE )
Tcode SALE ?3 for
a) Define Logical System
b) Assign Client to Logical System
Tcode SM59-RFC Destination

Tcode BD64 !V Check for Model view whether it has distributed or not
Tcode BD82 -- Generate partner Profiles & Create Ports
Tcode BD11 Getting Material Data
Tcode WE05 !V Idoc List for inbound status codes

Message Type MATMAS
Tcode BD10 !V Send Material Data
Tcode WE05 !V Idoc List for watching any Errors

1)a Goto Tcode SALE
Click on Sending & Receiving Systems-->Select Logical Systems
Here Define Logical Systems---> Click on Execute Button
go for new entries
1) System Name : ERP000
Description : Sending System

2) System Name : ERP800
Description : Receiving System
press Enter & Save
it will ask Request
if you want new request create new Request orpress continue for transfering the objects

B) goto Tcode SALE

Select Assign Client to Logical Systems-->Execute
000--> Double click on this
Give the following Information
Client : ERP 000
City :
Logical System
Currency
Client role

Save this Data

Step 2) For RFC Creation
Goto Tcode SM59-->Select R/3 Connects

Click on Create Button

RFC Destination Name should be same as partner's logical system name and case sensitive to create the ports automatically while generating the partner profiles

give the information for required fields

RFC Destination : ERP800

Connection type: 3

Description

Target Host : ERP000

System No:000

lan : EN

Client : 800

User : Login User Name

Password:

save this & Test it & RemortLogin

3)

Goto Tcode BD64 -- click on Change mode button

click on create moduleview

short text : xxxxxxxxxxxxxx

Technical Neme : MODEL_ALV

save this & Press ok

select your just created modelview Name :'MODEL_ALV'.

goto add message type

Model Name : MODEL_ALV

sender : ERP000

Receiver : ERP800

Message type :MATMAS

save & Press Enter

4) Goto Tcode BD82

Give Model View : MODEL_ALV

Partner system : ERP800

execute this by press F8 Button

it will gives you sending system port No :A000000015(Like)

5) Goto Tcode BD64

seelct the modelview

goto ~~>edit~~>modelview-->distribute

press ok & Press enter

6)goto Tcode : BD10 for Material sending

Material : mat_001

Message Type : MATMAS

Logical System : ERP800

and Execute

7)goto Tcode : BD11 for Material Receiving

Material : mat_001

Message Type : MATMAS

and Execute --> 1 request idoc created for message type Matmas

press enter

Here Master Idoc set for Messge type MATMAS-->press Enter

1 Communication Idoc generated for Message Type

this is your IDOC

Change Pointers

I know how to change the description of a material using ALE Change Pointers.

I will give the following few steps

1) Tcode BD61---> check the change pointers activated check box

save and goback.

2) Tcode BD50---> check the MATMAS check box save and comeback.

3) Tcode BD51---> goto IDOC_INPUT_MATMAS01 select the checkbox save and comeback.

4) Tcode BD52---> give message type : matmas press ok button.

select all what ever you want and delete remaining fields.

save & come back.

5) 5) go to Tcode MM02 select one material and try to change the description and save it

it will effects the target systems material desciption will also changes

6) goto Tcode SE38 give program Name is : RBDMIDOC and Execute

give Message type : MATMAS and Executte

ALE/IDOC Status Codes/Messages

-

01 Error --> Idoc Added

30 Error --> Idoc ready for dispatch(ALE Service)

then goto SE38 --> Execute the Program RBDMIDOC

29 Error --> ALE Service Layer

then goto SE38 --> Execute the Program RSEOUT00

03 Error --> Data Passed to Port ok

then goto SE38 --> Execute the Program RBDMOIND

12 Error --> Dispatch ok

Inbound Status Codes

50 Error --> It will go for ALE Service Layer

56 Error --> Idoc with Errors added

51 Error --> Application Document not posted

65 Error --> Error in ALE Service Layer

for 51 or 56 Errors do the following steps

goto WE19 ~~> give the IDOC Number and Execute~~>

Press on Inbound function Module

for 65 Error --> goto SE38 --> Execute the Program RBDAPP01 then your getting 51 Error

rEWARD POINTS

rEGARDS

Former Member · ‎07-04-2007

Hi see this It may be helpful.

1 BAPI Browser Tcode - BAPI

2 BAPI Object Builder Tcode - SWO1

3 Naming Convention for BAPI's "Naming Conventions:

1) Business Object: BUS0001 where 0001 is an active function group.

2) Function Module: BAPI_<object name>_<methodName>

3) Method Name : Max 30 chars. Should start with capital letter. GetDetail

4) Reference fields : Structures. Should start with BAPI…"

4 Steps for creating a BAPI "Steps for Creating a BAPI:

1) Create a Function Module in SE37 and assign it to an active Function Group.

(Check Remote Enable in attributes section)

2) Fill the Import (Input) Parameters for the RFC

3) Fill the Export (Output) Parameters

(BAPIRETURN IS MANDATORY)

4) Fill the Table parameters, if any

5) Write the “functionality” in the source code

6) Activate and Release the Function Module"

5 Attaching Methods to Business Object "Attaching method to BO:

1) Transaction - SWO1, create a Business Object.

Object Type – Internal technical key of the BO in the BOR.

Super Type – If we are using some existing parent node features

Object Name – Descriptive Name (This is displayed in list of Objects)

Name – Descriptive name to select Object Type.

Description – Text max 40 char

Program – ABAP prg generated, associated with the object type.

2) Go to Utilities ->API Methods -> Add method

3) Add key fields and attributes, if any

4) Generate the Object

5) Select the Added Method, Edit ->Change Release Status -> Object Component -> To be Implemented

6) Select Object Type, Edit ->Change Release Status -> Object Type -> To be Implemented

7) Select the Added Method, Edit ->Change Release Status -> Object Component -> To be Released

😎 Select Object Type, Edit ->Change Release Status -> Object Type -> To be Released"

6 How to check BAPI Functions?

Either in TFDIR table by specifying BAPI_* or from SE37 by specifying BAPI_*

7 Difference between BAPI and RFC BAPIs and RFCs both are remote function

modules. All BAPIs are RFCs , but all RFCs are not BAPIs . BAPI process a

business object and handles a busienss function completely. RFC perform a

function which process tables , files etc. but not a complete business function.

***********************************************************************************************

ALE

1 What is the purpose of ALE? Application Link Enabling (ALE) supports the distribution of business functions and processes across loosely coupled R/3 Systems. Connections from R/2 and non-SAP systems are supported.

2 Transaction codes for ALE Configuration & Status monitor of ALE Messages SALE & BD87

3 What are the Steps for Customizing ALE (Application Link Enabling) " 1) Setting up the Clients

2) Defining the Logical Systems for Clients

3) Defining the Communication Parameters

4) Modeling the Distribution

5) Generating Partner Profiles in Sending System

6) Distributing the Distribution Model

7) Generating Partner Profiles in Receiving System

😎 Creating the Master Data

9) Sending the Master Data

10) Monitoring the Communication"

4 Setting up Clients "First of all, you have to set up two clients to enable communication between the logical systems. The two clients may be located in the same R/3 System or in separate systems or servers. To set up a new client, from the SAP standard menu choose:

Tools -> Administration -> Administration -> Client administration -> Client maintenance

"

5 Defining Logical Systems for Clients "The name of the logical system is used as the unique ID. This name is assigned explicitly to one client in an R/3 System at a time. At any given point of time, you can assign only one logical system to one client i.e. one client can not have two logical systems attached to it. From IMG ->

Basis Components -> Distribution (ALE) -> Sending and Receiving Systems -> Logical Systems

To define the logical systems in the distribution environment, choose Define Logical System. Execute the function and enter a logical system and a short text for each of your clients and Save your settings. If you are using two clients in different systems, make sure your settings are the same in both systems. When using two clients in one physical R/3 System, you only have to make the settings once, since the entries are client-independent.

Assign the respective logical system to both the clients. Choose Assign Logical System to Client by 1)Execute the function in both clients. 2) To display the client maintenance screen , double-click on a client.3)In the Logical system field, enter the logical system to be assigned to the individual client.4)Save the entry"

6 Defining Communication Paramters (RFC Destinations) For the two logical systems to be able to communicate with one another, they must know how to connect to each other. The RFC (Remote Function Call) destination provides this information. From IMG -> Basis Components -> Distribution (ALE) -> Sending and Receiving Systems -> Systems in Network -> Define Target Systems for RFC Calls. Follow these steps: 1) Choose Create 2) • Enter the RFC destination. Use the name of the logical system that is to be the destination (use UPPERCASE letters only). Enter ‘3’ as the Connection Type and give short description for RFC Destination.As logon parameters, enter the logon language (for example, EN ), the logon client and the logon user (user ID with target system password).Once the RFC Destination is created, it is visible in one of the RFC Destination Types Screen e.g. Choose R/3 Connections. It will display a list of RFC Destinations.Then you have to enter Target Host and the system number either for the Remote Log-On or for Testing the current connection. Target Host is nothing but the application server to which you intend to connect. This name can be given either in the form of an IP address mode or just in the form of application server name. Save the settings.

7 Distributing the Customer Model "The systems involved in the communication, must know which messages are getting transferred from where to where. This information is stored in the distribution model. The distribution is based on the distribution model and is directly controlled by distribution model.From IMG -> Basis Components -> Distribution (ALE) -> Modeling and Implementing Business Processes -> Maintain Distribution Model and Distribute Views. Create the model view. Select Create model view. Enter the technical name and a description.

Define the sending and receiving systems and the message type. Position the cursor on Technical name and select Add message type.

A dialog box appears.

Enter the logical system name of the sender and the receiver and the message type.Save the model."

8 Generating Partner Profiles in Sending System After creating the model view, From IMG -> Basis Components -> Distribution (ALE) -> Modeling and Implementing Business Processes -> Maintain Distribution Model and Distribute Views.Go to Environment Menu and click Generate Partner Profiles. According to the Technical name of the model view and without changing any parameter execute the function and generate the partner profile.

9 Distributing the Distribution Model To generate the partner profiles in the receiving system, this system must distribute all the messages in the respective distributed environment. This is possible only when you transport your distribution view to the receiving system. So we need to distribute the model distribution view.To achieve this choose: From IMG -> Basis Components -> Distribution (ALE) -> Modeling and Implementing Business Processes -> Maintain Distribution Model and Distribute Views -> Edit -> Model View -> Distribute . Then we get a message saying that the corresponding Model View is successfully created / changed / updated. The next step after this is, we have to generate the partner profile for the receiving system. Only thing that we need to remember here is that we have to log-on to the receiver client and then you have to generate the partner profile. It is very much similar to the procedure as that of Generating the partner profile in the Sending system.Once this is done, the configuration of ALE is over.

10 General path for sending various documents For master data : SAP Standard Menu -> Tools -> ALE -> Master Data Distribution -> Cross Application For transactional data , instead of Cross Application, choose Logistics and navigate further.

If u hav any doubt u can get back while doing.

Regards,

Rajesh

Former Member · ‎07-04-2007

Hi Rajesh,

I am unable to get Object in my BAPI Repository.

what should be done?

Thanks&regards,

Kavita

Message was edited by:

Former Member · ‎07-04-2007

Hi,

See you release the object starting from object type.

Then release Interfaces,key fields(then whatever key fields u hav in that),Attributes,Methods(In that whatever method u have).

I think it may solve ur problem.

And that to see ur object in BAPI transaction with "OBJECT NAME".

If u still hav any problem do get back to me.

Regards,

Rajesh

Former Member · ‎07-04-2007

Hi,

SAP's Business Object Repository gives you an improved way to integrate business processes with external partners -- an increasingly necessary ability in the burgeoning e-marketplace economy.

by Alon Raskin

The age of e has had a profound effect on the IT industry. Not only has it changed our way of life, but it has also forced systems such as SAP to embrace a new era of openness. Marketplace demands for flexible automation of inter-business workflow and intelligent data exchange have forced formerly very proprietary ERP systems to begin helping customers integrate with other companies and with e-marketplaces data formats. For the first time, companies must expose their business processes to the outside world.

In order to achieve this openness, SAP provides a technical infrastructure for the R/3 product, the Business Object Repository (BOR), which provides a simple yet powerful mechanism for external systems to trigger core business processes (such as placing an order) without concern for the underlying data structure. This level of abstraction is beneficial because it decouples R/3 from the external system. Either system is therefore free to change its internal business processes without affecting the other. SAP provides this technical infrastructure using a component-based view of its system. Each component or object provides a view of the data and the business processes that interact with that data. External systems can access this data via BAPI methods, which in turn access the underlying data structures of the system. It is the responsibility of the object and the BAPI to ensure the integrity of the data. This encapsulation of the data not only lends itself to external interfaces, but by using objects from within SAP, you can greatly reduce implementation, testing, and maintenance effort via the promotion of code reuse.

Business Objects

A business object is a problem-domain entity that you model in the SAP system, such as SalesOrder, BillingDocument, and Employee. The BOR stores all the objects in the R/3 system. The repository is a group of all the objects in the R/3 system. If the focus of objects is to model atomic business processes then it can be said that the BOR provides an enterprisewide view of business processes. By designing your ABAP code to fit your business processes you increase the ability of that code to flex when those processes are altered or integrated with external systems. This had made the object-oriented approach, which the BOR provides, essential to developing inter-business or e-business functionality.

Attributes

A business object is primarily represented by its attributes. You perform actions, such as create, update, or delete on the attributes by calling the methods of the object.

Attribute NetValue of Object BUS2032 (SalesOrder).

The majority of attributes are data-dictionary fields (for example, the NetValue attribute is defined by VBAK-NETWR). When you access an attribute of an object, you execute a SQL statement that retrieves the corresponding field in the database.

Definition of attribute NetValue.

You can also define attributes that do not exist in the data dictionary. These attributes are called virtual attributes. For example, a business partner has an attribute called BirthDate that is stored in the data dictionary. You can add a virtual attribute to the BusinessPartner object called Age. The age of a business partner is not stored in the database, but you can calculate it using the current date and the birth date of the business partner. If you implement the ABAP code that calculates Age, every time you access the Age attribute, the code executes and returns the business partners age.

Definition of virtual attribute Age.

This is an excellent example of one of the tools that a component-based approach provides. The external system does not need to concern itself with how to gather the data that it requires. The calling program needs only to access the attribute for the data to be returned. This is how business objects decouple the calling program (whether it be in R/3 or external to R/3) from the internals of R/3.

The BOR lets you define multi-line attributes. These attributes define one-to-many relationships between an object and other fields. These objects can be defined in the data dictionary or can also be virtual attributes.

An attribute that uniquely defines an object in the system is called a key attribute. In the case of a SalesOrder, the key attribute is VBAK-VBELN (the TableName and FieldName). It is not uncommon for an object to have several key fields. An example of this is object is the SalesArea (BUS000603) object type which has SalesOrganization (TVTA-VKORG), DistributionChannel (TVTA-VTWEG) and Division (TVTA-SPARTE) as key fields.

Methods

As mentioned earlier, the methods of an object represent the actions you take with objects attributes. An action in this example would include retrieving the status of one or more sales orders based on specific criteria. Methods are analogous to function modules in that they have importing and exporting parameters as well as exceptions, which you view by selecting a method and clicking on the toolbar button. This allows external systems (or internal developments) to pass and accept parameters from these methods just as if they were using function modules -- allowing external systems to call methods.

In Figure 4, the methods shown with the green LED are BAPIs that are called specifically from external systems. They can, however, be called from within the system itself. The method shown with the stop sign is obsolete, but retained for backward compatibility, and should not be used in new developments.

Methods of SalesOrder.

Delegation and Subtyping

One of the most complex concepts in object-oriented development is that of inheritance. This concept lets you extend core functionality by creating a child of the parent object that inherits all of its attributes and methods. For example, a Manager object is a subtype (child) of the Employee object. The Manager object has all the attributes of an Employee object (such as EmployeeID or Name) but also has some extra attributes (such as CompanyCar or ParkingSpace). SAP has not implemented inheritance in the BOR. However, it has provided subtyping and delegation, which offer an alternative way to extend R/3 functionality.

Subtyping

A subtype of an object is another object whose creation is based upon a parent object (see the preceding manager/employee example). The subtype maintains references to all the attributes and methods of its parent object. This means that any methods and attributes defined on the parent can be executed and accessed on the child object. I have often heard less-experienced developers refer to subtyping as copying the parent object. Although the effects can be similar, in order to achieve an understanding of some of the more advanced concepts, such as interface inheritance, it is important to realize that this is not accurate.

If a subtype object were merely a copy of its parent, then all the code contained within the parent would be physically copied to the child. This is not the case. The subtype simply maintains references to its parents methods and attributes. The real difference is that the subtype lets you redefine these methods and attributes. You can easily add your own business rules to the parent methods by redefining the subtypes method. In the following example, I will show why this distinction is so important.

Subtyping Case Study

As an ABAP developer at Acme Tyres Pty. Ltd., you have been given the task of implementing some security measures for the companys online store. The requirement is simple: The password must be at least six characters long.

Modifying SAP code leads to costly and complicated upgrades due to the modified code being overwritten by the newly delivered SAP code. Therefore, The challenge is finding a way of implementing the business logic without modifying SAP code.

After some investigation, you realize that the method CHANGEPASSWORD (in BAPI) on the object KNA1 (Customer) is called when customers change their passwords. All you need to do is create a subtype of KNA1 and then redefine the CHANGEPASSWORD method adding the ABAP code to ensure that the password is a minimum of six characters long. It is of course not wise to change SAP code even assuming you have the passwords, which can be provided only be SAP. After the method is redefined, you just need to implement the business rules in ABAP.

FIGURE 5 Redefinition of ChangePassword method.

It is imperative that once you redefine the method it still behaves in a similar manner. You are allowed to add extra business logic, but the method must still change the password rather than do something unexpected, like delete a customer. This is particularly important when SAP is being accessed from external systems. The external system will expect a method to provide certain functionality. The developer should take care to ensure that this expectation is met.

Delegation

Now that you have implemented a new CHANGEPASSWORD method, you need to tell the SAP system to use the redefined version of CHANGEPASSWORD and not the version that was delivered on the KNA1 object. This is similar to object-oriented inheritance but the two concepts do have fundamental differences.

Delegation for objects.

By making an entry in the delegation table, you tell R/3 that before executing a method on KNA1, it should first check if that method has been redefined on the subtype. If it has, then the system executes the redefined method . If it hasn't, then the system executes the original method. Figure 7 illustrates this process.

Execution flow for methods with delegation.

This delegation is powerful because it lets you implement your own business logic without modifying any SAP code. As long as the objects are properly delegated, your method will be executed.

Responsibility

So far I have shown you two major components of an object, its attributes and methods. The difficulty in SAP is that it has traditionally been a data-driven, procedural-development approach. The BOR is not well understood by developers and managers and thus it is shunned by those that stand to gain the most from it. If managers and developers alike would take a formalized approach to development using business objects, significant savings in the development, testing, and maintenance phases would be achieved. This is due to the high level of re-use that business objects encourage.

Having said this, when a powerful tool is put into the hands of an inexperienced person, chaos can (and usually does) ensue. If object-oriented design principals are not adhered to, then the resulting code has poor reusability and maintainability. Although an in-depth discussion of design issues is beyond the scope of this article, I will introduce in the following section one of the more fundamental design aspects of BOR programming: Responsibility.

When you are given the task of creating a method or attribute on an object, one of the most important questions you should ask is, Does this attribute or method belong on this object? This question is fundamental to an object-oriented design and the answer can make a world of difference. Answering this question incorrectly has detrimental effects on the development effort resulting in methods and attributes strewn across myriad objects, with no coherent structure. If the methods and attributes were strewn across several objects, it would be more difficult to provide a uniform interface to external systems. If an external system wants to execute a particular business process in R/3, it may need to access several business objects, thus increasing coupling and reducing the layer of abstraction between R/3 and the external system.

Lets take, for example, the requirement to be able to update a sales order. This is a common requirement and one that SAP usually implements for you. For the sake of the example, lets assume that SAP has not implemented this method. You will need to implement your own UPDATE method on one of the business objects. The question here is: Which object? This question is what I term as defining responsibility. Which object is responsible for having the UPDATE method on it? As shown in Figure 4, the answer in this cases is BUS2032 (SalesOrder). If you put it on any other object then you run the risk of no one else knowing of its existence. Next time there is a requirement to update a sales order, the developer will develop an additional method. You would then have two separate pieces of code that implement the same functionality. This duplication doubles development, testing, and maintenance requirements. On large projects, this can become a real problem and a maintenance and testing nightmare.

SAP recognizes the challenges facing developers in the e-business era. It is aware that if it wants to take R/3 to the next phase, it needs to continue evolving the ABAP language and ensure that powerful development tools are available to SAP developers.

Rising to the challenge, SAP has begun developing extensions to the ABAP language called ABAP objects (see "Introducing ABAP Objects," in the IntelligentERP feature archive for an excellent introductory article to ABAP objects by Jürgen Heymann and Horst Keller). These extensions will provide ABAP developers with a full range of object-oriented tools. Eventually, these new extensions will make BOR obsolete. However, the use of object-oriented development is sure to be an integral part of future SAP developments, regardless of where the world of e takes us.

ALE-STEPS

ALE IDOC

Sending System(Outbound ALE Process)
Tcode SALE ? for
a) Define Logical System
b) Assign Client to Logical System
Tcode SM59-RFC Destination
Tcode BD64 ? Create Model View
Tcode BD82 ? Generate partner Profiles & Create Ports
Tcode BD64 ? Distribute the Model view

Message Type MATMAS
Tcode BD10 ? Send Material Data
Tcode WE05 ? Idoc List for watching any Errors

Receiving System(Inbound ALE )
Tcode SALE ? for
a) Define Logical System
b) Assign Client to Logical System
Tcode SM59-RFC Destination

Tcode BD64 ? Check for Model view whether it has distributed or not
Tcode BD82 -- Generate partner Profiles & Create Ports
Tcode BD11 Getting Material Data
Tcode WE05 ? Idoc List for inbound status codes

ALE IDOC Steps

Sending System(Outbound ALE Process)
Tcode SALE ?3 for
a) Define Logical System
b) Assign Client to Logical System
Tcode SM59-RFC Destination
Tcode BD64 !V Create Model View
Tcode BD82 !V Generate partner Profiles & Create Ports
Tcode BD64 !V Distribute the Model view

This is Receiving system Settings

Receiving System(Inbound ALE )
Tcode SALE ?3 for
a) Define Logical System
b) Assign Client to Logical System
Tcode SM59-RFC Destination

Tcode BD64 !V Check for Model view whether it has distributed or not
Tcode BD82 -- Generate partner Profiles & Create Ports
Tcode BD11 Getting Material Data
Tcode WE05 !V Idoc List for inbound status codes

Message Type MATMAS
Tcode BD10 !V Send Material Data
Tcode WE05 !V Idoc List for watching any Errors

1)a Goto Tcode SALE
Click on Sending & Receiving Systems-->Select Logical Systems
Here Define Logical Systems---> Click on Execute Button
go for new entries
1) System Name : ERP000
Description : Sending System

2) System Name : ERP800
Description : Receiving System
press Enter & Save
it will ask Request
if you want new request create new Request orpress continue for transfering the objects

B) goto Tcode SALE

Select Assign Client to Logical Systems-->Execute
000--> Double click on this
Give the following Information
Client : ERP 000
City :
Logical System
Currency
Client role

Save this Data

Step 2) For RFC Creation
Goto Tcode SM59-->Select R/3 Connects

Click on Create Button

RFC Destination Name should be same as partner's logical system name and case sensitive to create the ports automatically while generating the partner profiles

give the information for required fields

RFC Destination : ERP800

Connection type: 3

Description

Target Host : ERP000

System No:000

lan : EN

Client : 800

User : Login User Name

Password:

save this & Test it & RemortLogin

3)

Goto Tcode BD64 -- click on Change mode button

click on create moduleview

short text : xxxxxxxxxxxxxx

Technical Neme : MODEL_ALV

save this & Press ok

select your just created modelview Name :'MODEL_ALV'.

goto add message type

Model Name : MODEL_ALV

sender : ERP000

Receiver : ERP800

Message type :MATMAS

save & Press Enter

4) Goto Tcode BD82

Give Model View : MODEL_ALV

Partner system : ERP800

execute this by press F8 Button

it will gives you sending system port No :A000000015(Like)

5) Goto Tcode BD64

seelct the modelview

goto ~~>edit~~>modelview-->distribute

press ok & Press enter

6)goto Tcode : BD10 for Material sending

Material : mat_001

Message Type : MATMAS

Logical System : ERP800

and Execute

7)goto Tcode : BD11 for Material Receiving

Material : mat_001

Message Type : MATMAS

and Execute --> 1 request idoc created for message type Matmas

press enter

Here Master Idoc set for Messge type MATMAS-->press Enter

1 Communication Idoc generated for Message Type

this is your IDOC

Change Pointers

I know how to change the description of a material using ALE Change Pointers.

I will give the following few steps

1) Tcode BD61---> check the change pointers activated check box

save and goback.

2) Tcode BD50---> check the MATMAS check box save and comeback.

3) Tcode BD51---> goto IDOC_INPUT_MATMAS01 select the checkbox save and comeback.

4) Tcode BD52---> give message type : matmas press ok button.

select all what ever you want and delete remaining fields.

save & come back.

5) 5) go to Tcode MM02 select one material and try to change the description and save it

it will effects the target systems material desciption will also changes

6) goto Tcode SE38 give program Name is : RBDMIDOC and Execute

give Message type : MATMAS and Executte

ALE/IDOC Status Codes/Messages

-

01 Error --> Idoc Added

30 Error --> Idoc ready for dispatch(ALE Service)

then goto SE38 --> Execute the Program RBDMIDOC

29 Error --> ALE Service Layer

then goto SE38 --> Execute the Program RSEOUT00

03 Error --> Data Passed to Port ok

then goto SE38 --> Execute the Program RBDMOIND

12 Error --> Dispatch ok

Inbound Status Codes

50 Error --> It will go for ALE Service Layer

56 Error --> Idoc with Errors added

51 Error --> Application Document not posted

65 Error --> Error in ALE Service Layer

for 51 or 56 Errors do the following steps

goto WE19 ~~> give the IDOC Number and Execute~~>

Press on Inbound function Module

for 65 Error --> goto SE38 --> Execute the Program RBDAPP01 then your getting 51 Error

rEWARD POINTS

rEGARDS

Former Member · ‎07-04-2007

Hi,

plz go through the following links.....

FOR BAPI----

Business application Prograaming Interface is nothing but the Method of a Business object.

BAPI-step by step

http://www.sapgenie.com/abap/bapi/example.htm

list of all bapis

http://www.planetsap.com/LIST_ALL_BAPIs.htm

for BAPI's

http://www.sappoint.com/abap/bapiintro.pdf

http://www.sappoint.com/abap/bapiprg.pdf

http://www.sappoint.com/abap/bapiactx.pdf

http://www.sappoint.com/abap/bapilst.pdf

http://www.sappoint.com/abap/bapiexer.pdf

http://service.sap.com/ale

http://service.sap.com/bapi

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDAPII/CABFAAPIINTRO.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CABFABAPIREF/CABFABAPIPG.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCFESDE8/BCFESDE8.pdf

http://www.planetsap.com/Bapi_main_page.htm

http://www.topxml.com/sap/sap_idoc_xml.asp

http://www.sapdevelopment.co.uk/

http://www.sapdevelopment.co.uk/java/jco/bapi_jco.pdf

Also refer to the following links..

www.sappoint.com/abap/bapiintro.pdf

www.sap-img.com/bapi.htm

www.sap-img.com/abap/bapi-conventions.htm

www.planetsap.com/Bapi_main_page.htm

www.sapgenie.com/abap/bapi/index.htm

Checkout !!

http://searchsap.techtarget.com/originalContent/0,289142,sid21_gci948835,00.html

http://techrepublic.com.com/5100-6329-1051160.html#

http://www.sap-img.com/bapi.htm

http://www.sap-img.com/abap/bapi-conventions.htm

http://www.sappoint.com/abap/bapiintro.pdf

u can check the below the material also

what is BAPI?

BAPI stands for Business API(Application Program Interface).

I have answered this question before..

A BAPI is remotely enabled function module ie it can be invoked from remote programs like standalone JAVA programs, web interface etc..

You can make your function module remotely enabled in attributes of Function module but

A BAPI are standard SAP function modules provided by SAP for remote access. Also they are part of Businees Objest Repository(BOR).

BAPI are RFC enabled function modules. the difference between RFc and BAPI are business objects. You create business objects and those are then registered in your BOR (Business Object Repository) which can be accessed outside the SAP system by using some other applications (Non-SAP) such as VB or JAVA. in this case u only specify the business object and its method from external system in BAPI there is no direct system call. while RFC are direct system call Some BAPIs provide basic functions and can be used for most SAP business object types. These BAPIs should be implemented the same for all business object types. Standardized BAPIs are easier to use and prevent users having to deal with a number of different BAPIs. Whenever possible, a standardized BAPI must be used in preference to an individual BAPI.

The following standardized BAPIs are provided:

Reading instances of SAP business objects

GetList ( ) With the BAPI GetList you can select a range of object key values, for example, company codes and material numbers.

The BAPI GetList() is a class method.

GetDetail() With the BAPI GetDetail() the details of an instance of a business object type are retrieved and returned to the calling program. The instance is identified via its key. The BAPI GetDetail() is an instance method. BAPIs that can create, change or delete instances of a business object type

The following BAPIs of the same object type have to be programmed so that they can be called several times within one transaction. For example, if, after sales order 1 has been created, a second sales order 2 is created in the same transaction, the second BAPI call must not affect the consistency of the sales order 2. After completing the transaction with a COMMIT WORK, both the orders are saved consistently in the database.

Create( ) and CreateFromData! ( )

The BAPIs Create() and CreateFromData() create an instance of an SAP business object type, for example, a purchase order. These BAPIs are class methods.

Change( )

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

Delete( ) and Undelete( ) The BAPI Delete() deletes an instance of an SAP business object type from the database or sets a deletion flag.

The BAPI Undelete() removes a deletion flag. These BAPIs are instance methods.

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

Add<subobject> ( ) and Remove<subobject> ( ) The BAPI Add<subobject> adds a subobject to an existing object inst! ance and the BAPI and Remove<subobject> removes a subobject from an object instance. These BAPIs are instance methods.

http://help.sap.com/saphelp_nw2004s/helpdata/en/7e/5e114a4a1611d1894c0000e829fbbd/frameset.htm

http://www.sapgenie.com/abap/bapi/example.htm

http://help.sap.com/saphelp_46c/helpdata/en/9b/417f07ee2211d1ad14080009b0fb56/frameset.htm

http://searchsap.techtarget.com/originalContent/0,289142,sid21_gci948835,00.html

http://techrepublic.com.com/5100-6329-1051160.html#

http://www.sap-img.com/bapi.htm

http://www.sap-img.com/abap/bapi-conventions.htm

http://www.sappoint.com/abap/bapiintro.pdf

http://www.sapgenie.com/abap/bapi/example.htm

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDAPII/CABFAAPIINTRO.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CABFABAPIREF/CABFABAPIPG.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCFESDE8/BCFESDE8.pdf