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 BDC’s in standard application programs.

What is a BDC?

A little bit of background, 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 1 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 BDC’s 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 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 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

The upside

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 the using this tool for use 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 that 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 then experienced developer. So you can see that this is attractive from the viewpoint of a developer, but is that a good thing?

The downside

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 BDC’s 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 needs to be modified. Ooops 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.

Application structure comparison

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 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 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.

Later……………

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 , is it BW today or BI tomorrow, you know what I mean, but basically they are one and the same.

Additional References

1. SDN BDC Wiki

Phil

Phillip Avelar is a Managing partner at Advanced Solutions, based in Chicago. He works with SAP enterprises to optimize their supply chains, increase productivity and challenges the status quo.  He shares his passion for solving customers problems in his blog posts, industry articles and conference talks.