149、BAPI与自定义函数：一次RFC调用超时的血泪排查
那天半夜，MES系统抛过来一批生产报工数据，QP2函数一直超时。我看了一下调用栈，报错点在一个标准的BAPI：BAPI_PRODORDCONF_CREATE_TT。第一反应是数据量太大，但拆开看单条也超。后来把日志打开，发现每次都在同一个增强点卡住，而那个增强点，是之前某个顾问写的一个自定义函数，用“COMMIT WORK”硬生生嵌进了BAPI的标准流程里。
当时我盯着屏幕就想说一句话：BAPI不是你的私有函数池，别把什么都往里面塞。
先分清BAPI和自定义函数的位置
BAPI是SAP官方封装好的业务对象方法，它默认给你做了一整套事务控制、检查逻辑、状态更新、后续集成。你觉得它是个“函数”，可以随便调、随便改，那你就错了。它更像一个合同，规定了输入输出、错误返回、提交回滚语义。你调它，是在跟SAP签约，不是在自己家厨房里开火。
自定义函数就不一样了，那纯粹是你自己的工具。你可以约定输入输出，可以不管DB commit，可以在函数里做任何你认为“高效”的操作，但代价是——没有任何框架保护你。一旦出了错，责任全在你自己代码里。
很多ABAP新人容易犯的混用：拿BAPI当自定义函数用，往里塞一堆自己写的逻辑，或者拿自定义函数去模拟BAPI，结果该有的参数校验、返回结构、事务控制全都没有。
那个凌晨三点的教训：增强点里的COMMIT
回到开头的惨案。排查下来，BAPI_PRODORDCONF_CREATE_TT里挂了一个BADI实施，实施代码里调了一
