Skip to Content

Consider the SAP BAPI

http://help.sap.com/saphelp_46c/helpdata/en/7e/5e11ee4a1611d1894c0000e829fbbd/Image55.gifBatch 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.

/wp-content/uploads/2011/01/bullseye_target_miss_1600_clr_9251_337435.pngThough 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
You must be Logged on to comment or reply to a post.
  • .. for moving to the use of services. It's a lot easier to build a service wrapper for a BAPI than a BDC, so if you think you want to expose SAP functionality later on without SAP propietary technologies, then you'll probably wnat to investigate BAPIs as your first tool of choice.
  • As you mentioned correctly that it is configuration independent and does not dependent screen sequence!

    During upgrade it has been noticed that screen sequence has been changed / need extra validation due to introducing of new field.

    If you are using BDC then the program’s are bound to change, but BAPI can handle those scenarios as it always refer program of corresponding transaction.

    Although I agree, BAPI does not check all 'checks in transaction' but it has more advantage than disadvantage...

  • This blog would be been great if written in the year 2000/2001 discussing whether to use BDC or BAPI.  However the BAPI concept has been around for more than 10 years now.  A few technical comments:

    - CRM never supported BDC.  So if you are going to load data, you have to use the provided "BAPI's". 
    - Most BAPI's normally do invoke all properly desgined business logic checks.  You do code your business logic not in the UI layer, but in the business object layer right?
    - The enterprise services provided by SAP which are the logical successors of the BAPI framework also provide a way to load data screen independent.
    - BDC is a brittle technology that is always runs the risk of one minor configuration breaking the entire program.

    Take care,

    Stephen

    • Some great points Stephen however take consideration of the fact that BDC's are still used EXTENSIVELY by SAP customers both old and new and ERP in particular. Additionally, while you are correct, that CRM never 'officially' supported BDC it does support GUI scripting and there are a couple of edge case uses of BDC with CRM.

      Well designed programs, as you correctly state, should code business logic in the business object layer however when using customized Java and ABAP programs that are derivatives of standard programs; business and consultants don't always incorporate all the catches and hooks in the business layer. 3rd party integrations for example don't necessarily need to be integrated in the business layer when they are incorporated into the UI layer to do things like branch business functions to non SAP systems.

      I think your use of the word brittle to describe DC's is right on!

      Thanks for reading and commenting.

      Clinton

      • For ERP just because everyone is still using the BDC technique does not make it the first choice of solution for new development.  If that were the case we could still tell folks to use the ITS for all their web applications.  IMHO BDC should be used as a method of last resort.

        Honestly I would love to know what use cases in CRM you think are still approriate for BDC?  With the XIF adapter and the webservices tool available in CRM 7.0, IMHO there are no valid reasons for using BDC in CRM, besides the fact that the SAP GUI is not supported on CRM releases above CRM 5.0 for business user work except in exceptional use cases.

        Take care,

        Stephen

        • I agree, BDC should NOT be the first choice for building an integration.

          If you have a business process that has moderate to high volumes of data creation and maintenance requirements that reoccur on a frequent basis then you should be leveraging appropriately designed and developed solutions that address that business requirement.

          I am still seeing transaction based recording increasingly of interest to SAP customers who are either on older versions of CRM (there are still many of them out there), or are discovering that the role based portal views and maintenance screens of their data are suboptimal for rapid creation and maintenance. Invariably these same customers don't want to make any significant investment in what they see as either 'plan to discard or upgrade' technology. This is admittedly often positioned from a tactical rather than a strategic viewpoint.

          Some typical scenarios are:
          Business Partner Maintenance
          Opportunity Maintenance
          Change Organizational Model 

    • Stephen,
      That was exactly my thought when reading this blog: Neat blog, but ten years late.
      Of course BDCs have not completely disappeared and every once in a while (very rarely), a valid use case shows up. In general, however, there are plenty of integration or migration techniques and tools that I would check first, most prominently Enterprise Services or other SOAP Web Services, BAPIs, non-BAPI-compliant RFCs, IDocs, Direct Input, LSMW, and in the near future Gateway or other RESTful interfaces.
      Cheers,
      Thorsten
  • I, too, use BAPIs whenever possible.  However, I usually end up coding a BDC as well to create error sessions for our end users.

    Thanks for the great blog.  Definitely still a discussion worth having!