Does SAP BAPI has proprietary communication format or an open one?

I've just been dumped into the middle of a SAP project and I need to use SAPs BAPIs to pull a bunch of information out of the client SAP system.

Given that SAP is a closed platform I've been having trouble finding a high-level overview of what is BAPI. I realize you could spend a lifetime working with these ERP system and still not understand the whole thing, so I just want a basic overview so I can talk intelligently with "The Client's" SAP folks.

Specifically my questions are:

1. Is BAPI just a wrapper for SOAP and/or XML-RPC, or is it a completely proprietary communication format?

2. How can these APIs be consumed from external PHP?

3. I've seen the acronym ABAP in relation to these BAPIs, is it somewhat related?

   开发者_开发百科

BAPI ("Business API") is SAP's interface specification and a way of getting information out of the system. I'd say the simplest way to look at it is as a remote procedure call into the SAP system, giving you access to the data and functionality (writtten in ABAP) that is in the SAP. It gives you some API to pull data out of the system (e.g. an order), change it in you application (e.g. add positions to the order) and then post it back and also call business functions (e.g. post this order so it is further processed in the SAP system).

There are wrappers for calling BAPIs from a number of languages. Just google or search within SAP's help system or the online sap developer network at sdn.sap.com

ABAP is the programming language most of the SAP system is written in. It's basically a 4/GL version of COBOL with some SQL added in.

BAPI stands for Business Application Programming Interface.

SAP's goal when introducing BAPI's was to provide ...

• well-defined
• stable
• implementation-independent
• well-documented

business API's that provide standardized access to SAP solutions on a semantic level.

Still, BAPI's are proprietary SAP interfaces.

The BAPI interfaces provide a unified access to the application level functionality, independent of the type of call: Both synchronous and asynchronous processing can be triggered by using these interfaces.

Synchronous processing of a BAPI will result in the execution of a RFC (Remote Function Call, SAP's proprietary RPC protocol).

Asynchronous processing makes transparently use of ALE (Application Link Enabling, SAP's proprietary EDI format).

Products like the webMethods SAP Adapter (aka SAP Business Connector) provide bidirectional service level access to BAPI's as well as the lower level RFC and ALE protocols from/to a remote destination.

Using these tools there is no need to bother about ABAP, the 4GL programming language all the SAP business logic is implemented in.

There are also several XML mappings defined for BAPI's (as well as RFC's and IDocs) that allow to transmit business documents within an XML envelope. These are most noticeable

• bXML (Content-Type: application/x-sap.busdoc)
• RFC-XML (Content-Type: application/x-sap.rfc)
• IDoc-XML (Content-Type: application/x-sap.idoc)

as well as SOAP.

1. Forget about bapi for a second. SAP has a proprietary communication protocol called RFC( remote function call). SAP provide a dll ( or shared library for *nix) that you can use to call functions in SAP from c. SAP also provide wrappers of this dll for java and .net. And there are open source wrappers of this dll for php, python, perl and ruby. So the process is. a) somebody develop a (remote enabled) function in abap. b) you can use the rfc dll, with the wrapper for your language of choice, and call this sap function. c) everybody is happy.

   Lets return to BAPI. Based on the technology described in the previous section. SAP decided to create a set of functions that do business stuff. And they decided to call them BAPI. Because the name "Functions that do business stuff" isn't cool.

2. Here is the php extention for calling sap. You can also find a lot of information about php and sap in the sap sdn.

3. ABAP is the language of the sap platform.

BAPIs are remotely enabled function modules that have some programming "standards" attached to them if one wants to call them "BAPIs", e.g. messages returned in certain formats, parameters typed a certain way. They really are nothing more than SAP function modules enabled for remote communication via a radio button.

I disagree that one should not have to write SAP code, because SAP has provided so many BAPIs to cover most of the standard stuff. Just about every implementation requires code and the SAP delivered stuff is just the base. The managers and sales types will say differently, but that is just not reality.