Factors in choosing suitable method for BDC

by Neelkanth

There are several factors which will influence your choice between a batch input session method, call transaction or a BAPI. I will try to list out some of them here.

First is to look for a BAPI. The reason is that BAPIs are supposed to be APIs provided by SAP that protect the interfacing with a particular application in SAP(say sales order). They encompass all the business logic of the corresponding online transactions. Advantages are that they are supported by SAP and their call interface is very stable. Disadvantage is that most of them are synchronous calls and if you are doing massive data conversions, this may be a resource drainer. Also, with BAPIs, you not only need to read the return messages for errors and take corrective action, but also, you need to code for storing the source data so that you want to reprocess it. Sometimes BAPIs may not provide all the features of an online transaction and so they may limited to what data they can store, like texts for instance. If your data requires you to store texts along with the object and the BAPI doesn't provide you with the parameters for passing the texts, then you may end up doing it in two steps.

Batch Input session and call transaction are essentially the same in the sense that they both go through screen flows as opposed to direct data updates. But the major difference between the two is that one is done in batches (good for mass uploads like conversions) and the other is not done in batches. Once a batch is submitted for processing, the system processes it just like a call transaction. Batch inputs are good for massive data loads where you want create several small chunks of such call transactions and process those batches when you have system resources available. They may also be good if you want to retain the transaction data for error reprocessing, but this will not be your source data record.

Call transactions are good only if you want to handle the return messages in your code and act accordingly. So, let us say you create a sales order using call transaction method, and as soon as you get the success message with a sales order number, you want to do something else, then a call transaction is useful. Similarly, if you have an error returned from the call transaction, then you want to report it(error notification), store the source record (may be in an error file or a table), or store the error transaction data (by inserting into a batch input session) for reprocessing. So a call transaction will give you the control after the transaction call is completed. If you want that control, you can use it. But remember that it uses up a lot of resources unless you take care of how it is processed. The latest mySAP enjoy transactions have a lot of controls and may not be suitable for call transaction method.

So what do you look at to decide?
1. Your data volume
2. Your frequency (one time vs. periodic interface)
3. Availability of the functionality you seek with the data you have. Do I have a BAPI that can achieve the desired results I want? Can I record the transaction to do a call transaction or batch input session?
4. Your error handling requirements. Do I need to notify? Do I need to persistently store my source records for any potential reprocessing? Do I need to log the results for audit requirements?

There are others that I can talk about like are there standard SAP programs for the data loads(SXDA, SXDB, LSMW etc)? or Are there IDOC function modules that suit the purpose? Are there regular function modules that I can use although not recommended as SAP can change them without notifying you, but again not insurmountable if you have a good upgrade methodology)


 

Please send us your feedback/suggestions at webmaster@SAPTechnical.COM 

HomeContribute About Us Privacy Terms Of Use • Disclaimer • SafeCompanies: Advertise on SAPTechnical.COM | Post JobContact Us  

Graphic Design by Round the Bend Wizards

footer image footer image