Batch Data Communication (BDC) has been around for sometime now and when it was introduced it was with the objective of making the loading of data into SAP, easier. Given the many permutations and combinations of SAP configuration that any given SAP system can have, it has served business well, being used in a variety of functional areas and with a variety of SAP and third party tools including LSMW. BAPI's on the other hand, haven't been around for as long but interestingly they are usable with many of these tools too.
The acronym stands for Business Application Programming Interface and the approach and supporting technology components were implemented as part of a fashionable initiative to help wider use of SAP. Use in the business environment by providing consistent and stable ways to communicate with SAP systems in a configuration independent fashion.The principle being, that BAPIs are largely configuration independent.
The SAP APIs, like the APIs in other products, provide customers and partners with standardized access to SAP systems on a semantic level. While still proprietary to SAP, they nonetheless provide a framework for access to application level functionality synchronously or asynchronously and more importantly, independent of the type of interface connecting to them.
Unlike BDC sessions, synchronous BAPI sessions, passed over an RFC call to the SAP system send data and wait on a response from the SAP system regarding call validity or outcomes from the SAP system.
As part of the creation of the BDC session you might pick and choose fields for data entry based on the flow logic of the application screens, customized or not. The transaction you execute as part of the BDC session recording will guide you as to which fields need to be completed; give you warnings etc. Provided you send precisely the correct field parameters and valid data across an RFC connection the BAPI will work and requires no ABAP development work on the SAP side. This has its advantages over BDC sessions when you want to expose this capability to ordinary users or other solution providers in a relatively simple way. Conversely exposing a BDC or a BAPI within the SAP UI requires building an ABAP wrapper or dynpro form in ABAP that requires completion by the user and often also requires some basic knowledge of the transaction and its requirements to start with.
Since field validity and correctness will be checked by the BAPI over an RFC connection and an appropriate response returned to the connecting system indicating BAPI execution success or failure. For owners of external sources of data for SAP systems the BAPI is a boon for creating integrations without a need to have an intimate understanding of SAP itself. All this is of course the theory of the BAPI however the reality of implementation an application tends to be a little more complex.
Though the BDC is much maligned by SAP technologists as only slightly better than screen scraping, the reality of working with BAPIs is pretty harsh in contrast. BAPIs don't handle all the flow logic checking and enhancements embedded in a transaction to meet the requirements of business so sometimes things are missing. Standard BAPIs are often pretty rudimentary and although they should support all business rules often times we find that they don't.
Conceptually the BAPI then, lends itself to specific scenarios that are primarily focused on non-SAP sources talking to SAP. Things like sales orders, purchase orders and various warehouse actions lend themselves perfectly to this integration scenario. This is however a domain that has been well serviced by BDC based solutions in the past but it maybe better serviced in some scenarios by BAPIs for a couple of reasons.
Others have suggested that BAPIs work well for 'higher end usage' though quite what that is exactly I cannot say, I suspect they mean simple application. What I can say is that it is easier to change attributes of 'Additional Data' for materials in MM01 such as language descriptions or UoMs using a BAPI,than it is using a BDC session or gui scripting methods.
Consider also, that BAPIs do perform faster than BDC sessions, hands down. BAPIs carry less overhead than the BDC sessions in terms of screens etc. BAPIs are also relatively immune to SAP upgrades and depending on the characteristics of the BAPI vs. the Tcode, can have much more basic requirements to achieve your business objective, in the end this may be a better scenario.
Also give consideration to BAPIs when you look to try and automate CRM, APO, SRM and Portal based requirements and finally remember that BAPIs are bi-directional, there are many that are reports or the basis for reports so you can often use BAPIs to pull fromas well as push data to your SAP systems.
Winshuttle supports the use of BAPIs as an alternative method to create or maintain data in SAP. This is particularly important where you might have concerns about invoking a transaction over RFC using the call transaction function.
9 Comments
