Solved: ALE, EDI, WAS, BSP, BAPI

Former Member · ‎06-05-2007

HI ALL,

CAN YOU TELL ME A BRIEF ABOUT ALE, EDI, WAS, BSP, BAPI AS IT IS VERY COMMON IN EVERY INTERVIEW ?

REGARDS

RAJARSHI

Former Member · ‎06-05-2007

Hi rajashri,

the topics u have asked is like seperate module, u may know that.

i'll give u some details so that u can understand about that topics.

ALE and EDI are the interfaces used to send the documents in and out of the sap systems.

EDI is used to send or receive the document to your customers or vendor, he may be using SDAP or NON-SAp systems,

hence we convert the sap document to idoc and then the Generated idoc are sent to them through a subsystem,

ALE:

• The integration service, <b>Application Link Enabling (ALE)</b>

The ALE integration service enables business processes carried out in different R/3 and non-SAP systems to be integrated.

It involves distributing business objects across the systems using the ALE distribution model.

The ALE (Application Link Enabling) concept available in R/3 (Release 3.0) supports the development of applications across different SAP systems.

It incorporates the exchange of business information across these systems whilst ensuring consistency and integrity of the data.

This functionality is achieved with the use of Idocs (Information Document) as opposed to the use of a centralised database.

Bapi: External applications can access SAP business objects through standardized, platformindependent

interfaces - Business Application Programming Interfaces (BAPIs). SAP

business objects and their BAPIs provide an object-oriented view of R/3 business

functionality.

This guide provides an overview of the Business Framework, SAP business objects and

SAP interface types and their BAPIs as well as the Business Object Repository where

business objects and BAPIs are defined and stored.

<u>and some important terms in BAPI are</u> \

Business components

SAP business components provide autonomous business functions and consist of

business objects. For example, the business objects, Employee and Applicant are

assigned to the business component Human Resources. Business processes are either

implemented within a business component or across several components (distributed

business processes).

• Business objects

The object-oriented structure of the R/3 System is based on business objects. They

encapsulate business data and functions and define the scope and the boundaries of a

business component.

• Business Application Programming Interfaces (BAPIs)

BAPIs are interfaces for business objects. Together with the business objects, BAPIs

define and document the business interface standard.

BSP:

BSP is a web based technology which is integrated into the ABAP Workbench(as of WAS 6.10). You can develop web based applications using ABAP and html(or htmlb).

http://help.sap.com/saphelp_470/helpdata/en/e9/bb153aab4a0c0ee10000000a114084/frameset.htm

Former Member · ‎06-05-2007

Hi

Refer ther link below

http://www.sappoint.com/PHPWebUI/index.php5?menu=documents&id=21&name=SAP%20ALE%20/%20EDI

http://www.sapmaterial.com/index.html

Former Member · ‎06-05-2007

Hi Rajarshi,

IDOCS:

IDOCS are intermediary documents which are like CARRIERS of the data

IDOCs are safe to transfer data, but less volume of data. User is not allowed to access (modify) the data like PSA. IDOCs have 3 parts.

1. Control Record - SOURCE & TARGET details,

2. Data Record - Here comes your query....

Info IDOC - It contains all the technical details related to the data load i.e. Request NO, No of Data Packages, USER, DATE, TIME, LOGICAL SYSTEM, etc. Info IDOC is also ONE segment, the 1 sr segment.

Here data will not be there.

Data IDOC - These are the ones which hold the data. The total no of records are made into Data IDOCs i.e. if 99 records are there then 99 Data IDOCs will be there and all these will be divided into 99 segments.

Hence the total number of Segments in IDOC is 100.

Info IDOC + Data IDOCs = Total no of Segments

1 + 99 = 100.

3. Status Record - Here the status of the data transfer will be available.

ALE:

ALE is Application linking & Enabling which enables to interface SAP with other modules

Pl go through below links as they provide all the required info on ALE & IDOC's:

ALE / IDOC:

Please check this online document for ALE and IDoc.

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

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

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

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

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

Also check this links for additional information.

http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm

http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc

http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419

http://www.netweaverguru.com/EDI/HTML/IDocBook.htm

http://www.sapgenie.com/sapedi/index.htm

u will have enough material from above .....

Mostly SD consultant doesn’t deal with EDI, Idocs but it’s always good to have knowledge,

EDI

EDI concept in SD: the EDI concept is intended to realize the sales and distribution process completely automatically with the help of electronical documents. These documents are sent from one customer to another, are processed mostly on the background and give a possibility to realize the sales process extremely efficiently.

If MM-customer would like to purchase the goods then he creates the IDOC of type ORDERS and send it to SD-customer. On the SD-side the IDOC is processed via the function module IDOC_INPUT_ORDERS and creates the sales order. As confirmation the SD-side can send to MM-side the Order-Response IDOC (function IDOC_OUTPUT_ORDERS). The MM-customer can every time send a change to the existing order, then on SD side the ORDCHG IDOC will be processed. It can change the order like in VA02. The creation of the invoice can be made via IDOC of message type INVOIC (function IDOC_OUTPUT_INVOIC).

So, the process can be realized completely automatically between SD and MM partners with the help of IDOCs: ORDERS, ORDCHG, ORDRSP, and INVOIC.

That's all concerning the SD-EDI.

Additional processes in SD, where EDI are used:

1) application of delivery schedules to the scheduling agreement: IDOC of type DELINS

2) creation of a delivery order to the scheduling agreement: IDOC of type DELORD

3) creation of external agent service delivery to scheduling agreement: IDOC of type EDLNOT

4) creation of credit advice / credit memo in the frames of self-billing: IDOCs of type GSVERF, SBWAP and for external invoice creation SBINV.

It is all processes which are realized in the SD module via EDI.

Go through this, You will get better idea on EDI,ALE,IDOCS

The interface concept of the classic R/3 is based on two different strategies: Remote Function Calls (RFC) and data exchange through IDoc message documents. RFC makes direct and synchronous calls of a program in the remote system. If the caller is an external program it will call an RFC-enabled function in R/3 and if the calling program is the R/3 system it will call an RFC-function in another R/3-system or it will call a non-R/3 program through a gateway-proxy (usually rfcexec.exe). BAPIs are a subset of the RFC-enabled function modules, especially designed as Application Programming Interface (API) to the SAP business object, or in other words: are function modules officially released by SAP to be called from external programs.

IDocs are text encoded documents with a rigid structure that are used to exchange data between R/3 and a foreign system. Instead of calling a program in the destination system directly, the data is first packed into an IDoc and then sent to the receiving system, where it is analyzed and properly processed. Therefore an IDoc data exchange is always an asynchronous process. The significant difference between simple RFC-calls and IDoc data exchange is the fact, that every action performed on IDocs are protocolled by R/3 and IDocs can be reprocessed if an error occurred in one of the message steps.

While IDocs have to be understood as a data exchange protocol, EDI and ALE are typical use cases for IDocs. R/3 uses IDocs for both EDI and ALE to deliver data to the receiving system. ALE is basically the scheduling mechanism that defines when and between which partners and what kind of data will be exchanged on a regular or event triggered basis. Such a set-up is called an ALE-scenario.

The philosophical difference between EDI and ALE can be pinned as follows: If we send data to an external partner, we generally speak of EDI, while ALE is a mechanism to reliable replicate data between trusting systems to store a redundant copy of the IDoc data. The difference is made clear, when we think of a purchase order that is sent as an IDoc. If we send the purchase order to a supplier then the supplier will store the purchase order as a sales order. However, if we send the purchase order via ALE to another R/3 system, then the receiving system will store the purchase order also as a purchase order.

BAPI:

BAPI (Business Application Programming Interface) is a set of interfaces to object-oriented programming methods that enable a programmer to integrate third-party software into the proprietary R/3 product from SAP. For specific business tasks such as uploading transactional data, BAPIs are implemented and stored in the R/3 system as remote function call (RFC) modules.

BAPIs (Business Application Programming Interfaces) are the

standard SAP interfaces. They play an important role in the

technical integration and in the exchange of business data

between SAP components, and between SAP and non-SAP

components. BAPIs enable you to integrate these components

and are therefore an important part of developing

integration scenarios where multiple components are

connected to each other, either on a local network or on the Internet.

BAPIs allow integration at the business level, not the

technical level. This provides for greater stability of the

linkage and independence from the underlying communication

technology