否。

我很少做出这样的明确声明，但BDC永远不会比BAPI更好。 当所需的功能无法通过其他方式使用时，我们将BDC作为最后的选择。

不确定该问题来自何处，但是即使对BDC是什么以及其工作原理有基本的了解，也很容易 看看它为什么烂。 我的梦想是永远不必在SAP中使用BDC，我希望这也是SAP的梦想，即最终实现客户的梦想。

Sandra Rossi ，这就是为什么我说我很少发表这样的言论。 :)我的此类异常问题是，"一次调用"迅速成为常规的生产程序，在下一次升级中会中断，并且花费大量时间来重写它。 因此，我还不准备承认这一点，对不起！ ：）

使用BDC的标准SAP示例是根据ORDERS IDOC消息创建的销售订单。 这就是所谓的IDOC处理功能模块IDOC_INPUT_ORDERS。 ，他们会以一种称职的，彻底的方式实施这些修改和增强，因此该功能也可以通过他们可以使用的一点点官方API来使用，或者根本不使用-在少数情况下，这确实是不可能的或不可行的 这样做：）

你好 Samriddhi N ，

您真的不想知道BDC的用例，如果有可用的BAPI，就不需要使用BDC。

您的BDC永远不可能是任何BDC的永久解决方案

尽管有多种原因可以证明BAPI优于BDC，但是您可以考虑这种简单情况。

BDC完全基于屏幕录像 概念。 在完成BDC录制后，屏幕上多年来所做的任何更改都如下所示：

1）添加字段

2）将验证添加到任何现有字段

可能会使BDC程序崩溃。 而且我们正在谈论的所有屏幕更改，执行此操作的功能和技术顾问可能不一定知道该屏幕存在的BDC程序，因此问题始终存在。

从不使用BDC

注意！

应尽可能在BDC上使用BAPI。 但是，有时在少数情况下，这种说法是不正确的（请注意，这取决于任何开发人员已经完成的开发类型）。

场景-有时很少有客户根据需求执行很少的修改或隐式增强，而对于新的需求集使用BAPI时可能不可用。

默认情况下，BAPI优先于BDC； 但某些情况下可能会使用BDC：

• 根本没有BAPI
• BDC和BAPI的行为不同（罕见但确实发生）
• 屏幕上有很多自定义字段，后面带有检查和计算，这在BAPI上不可用。 最初的开发人员应该将其实现为类或其他东西，但是如果他/她没有这样做，BDC可能会在短期内节省一天的时间。