The increasing use of BDCs in standard application programs in the past couple of years has prompted me to write this article.
What is a BDC?
A little bit of background: BDC, which stands for Batch Data Conversion, is a technique developed by SAP to allow developers to quickly develop a routine to mimic users entering data using standard transactions, but in an automated fashion. This was a tool that made our implementations so much easier. Companies that were not familiar with the tools developed elaborate custom programs to upload legacy data. Consultants familiar with the BDC technique performed data recordings, then developed simple apps that uploaded the data and submitted it to the BDC. We used to have a standard one-day turnaround time for a BDC conversion program, and we estimated five+ days for a custom-built conversion program. Now, onto the debate.
What is the Issue?
We regularly work with customers on system performance issues. One of our standard checklists is to look for applications that use BDCs as they are a potential source of overall system performance and tend to be less responsive for users. This generally starts a needed discussion about the associated impact, so let me explain why this this is an issue and, in my opinion, should not be allowed in your SAP environment.
As I stated above, the BDC technique was intended to allow fast development of conversion routines, with the following features:
- Records user transactions against dialog transactions, which can then be executed to load data from a file (text, Excel, etc.) or calling program.
- Executes any validations that are part of the standard transaction and are configured by the user. This includes user exits, BADIs, etc.
- Simple to create with or without a developer. Recordings do not require a developer key.
This is great for productivity when you are trying to produce a one-time or occasional load routine, which is how it was intended. But what about using this tool in a standard transaction? And why would anyone consider using this technique if it is not appropriate? As one development lead put it to me: “Because the programmer is lazy.” The truth is that developing an application using a BDC is easier. Remember my list of features above. Since the system executes the standard dialog transaction, a programmer does not need to develop validation routines, database lookups, etc,. so less analysis and design work is necessary. This can be accomplished by a less-experienced developer. You can see how this is attractive from the viewpoint of a developer, but is it a good thing?
To provide this simplified environment, a BDC requires a bit of overhead as it steps through the screens. (Remember: the system is actually executing the SAP screens whether you are displaying them or not.) From a user perspective, this is ok since all the rules are followed. Buy from a system and support standpoint, this is not good. Literally, the application is calling an environment that is calling a transaction (see the figure below).
Though the application performance impact to the user might be negligible, it is still placing a load on your environment and it all adds up.
You’ll understand this if you’ve had to update applications that were written using BDCs after a configuration change or an upgrade. Since the BDC is written to the screen, if a screen changes in the transaction being called, it may no longer work and will need to be modified.
A high-level perspective:
How to do it right
The alternative, of course, is to write the routines that include the processing logic that the native screens execute. (Isn’t that what we are supposed to be doing anyways?) This requires more time but results in less support costs, reduced impact from upgrades and, in some cases, where application performance is actually substandard, can result in improved user productivity.
Over the years, we have studied the gradual increase in the number of custom applications in use at client sites and we do not see this changing any time soon. So the impact of the increased use of this technique over time will grow and we’ll be talking about this again and again. As companies outsource their development 4,we are seeing an increase in BDC use and you can gauge this also by reading all the questions on SDN about writing BDC’s.
After discussing the performance issue associated with a BDC application recently with a development manager he told me that going forward any application that uses a BDC will require development manager approval first and they will add it as part of code reviews (you are doing code reviews right?) for offshore development to make sure it is not used. Not a bad idea.
To those that asked me to write this down to advance the conversation I hope this helps to summarize the comments you gave me and also provide sufficient details for you to advance the conversation within your own company.
Note: BDCs are also referred to as Batch Data Input and Batch Data Communication. Unfortunately, as most of us in the SAP space know, terms are never consistent but basically they are one and the same.
Phil Avelar is a Senior SCM consultant at Advanced Solutions, based in Chicago. He shares his passion for solving customers problems in his blog posts, industry articles and talks. When he’s not writing, he’s working with customers to develop and apply innovative solutions to common problems in the supply chain.