Not sure why, but I felt today was a good day as any to address a topic I have been trying to get to for some time: the increasing use of BDCs in standard application programs.
What is a BDC?
A BDC, which stands for Batch Data Conversion, was a technique developed by SAP to allow a developer to quickly develop a routine to mimic a user entering data using a standard transaction, but in an automated fashion. This was one of those tools that made our implementations so much easier. For those companies that were not familiar with the tools, they would develop elaborate custom programs to upload legacy data, whereas consultants that were familiar with the BDC technique performed data recordings and then developed simple apps that uploaded the data and submitted it to the BDC. We used to have a standard turnaround time of one day for a BDC conversion program, whereas we estimated 5+ days for a custom-built conversion program. OK, 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 also tend to be less responsive for users. This generally starts a needed discussion and what the associated impact is. So, let me try and explain why this this is an issue and why in my opinion, it should not be allowed in your SAP environment.
As I stated above, the BDC technique was intended to allow fast development of a conversion routines with the following features:
- Ability to record a user transaction against a dialog transaction, which can then be executed to load data from a file (text, excel, etc.) or a calling program.
- Executes any validations that are part of the standard transaction and or configured by the user - this includes user exits, BADI’s 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? Well, let me first answer the question as to why would anyone consider using this technique if it is not appropriate? To put it as one development lead put it to me, “Because the programmer is lazy.” The truth is, developing an application using a BDC is simpler. 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 and can be accomplished by a less-than-experienced developer. So you can see, this is attractive from the viewpoint of a developer. But is that 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, but from a system and support standpoint this is not good. Literally, the application is calling an environment that is calling a transaction (see 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.
Those of you that have had to update applications that were written using BDCs after a configuration change or an upgrade will understand this one. If a screen changes in the transaction being called, since your BDC is written to the screen, it may no longer work and will need to be modified. Oops - guess that was never considered when the application was developed.
One of our developers explained the performance impact with a diagram he put on a white board (I copied it here, of course I made it look nicer) and this helped me get my head around it.
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, improved user productivity.
Over the years, we have studied the gradual increase in the number of custom applications in use at client companies 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, we are seeing an increase in BDC use and you can gauge this also by reading all the questions on SDN about writing BDCs.
After discussing with a development manager the performance issue associated with a BDC application, I was told that going forward, any application that uses a BDC will require development manager approval first. 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 that BDCs are also referred to as Batch Data Input and Batch Data Communication. Sadly, as most of us are aware in the SAP space, terms are never consistent in our world. It may be BW today or BI tomorrow, you know what I mean, but basically they are one and the same.